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I.  INTRODUCTION 


The  Integrated  Control  System  Engineering  Support  Contract 
covered  the  period  of  17  September  1979  through  2  April  1984.  The 
objective  of  this  effort  was  to  provide  engineering  analysis  and 
software  support  to  the  Flight  Control  Division  of  the  Air  Force 
Flight  Dynamics  Laboratory  on  several  programs  concerned  with  the  for¬ 
mulation,  development,  and  evaluation  of  advanced  concepts  in  flight 
control  technology. 

1.1  SCOPE  OF  WORK  PLANNED 

This  effort  was  intended  to  make  available  engineering  analysis 
and  software  development  support  to  programs  across  the  Flight  Control 
Division.  Among  the  tasks  to  be  performed  were:  The  development, 
test,  integration,  and  documentation  of  software  and  specialized 
interfaces  for  use  in  the  Flight  Control  Development  Laboratory, 
including  support  of  the  Digital  Synthesis  Flight  Engineering 
Facility;  support  of  advanced  development  programs  through  analysis 
in  the  area  of  redundancy  management  for  multi-channel  flight  control 
systems  and  independent  assessment  of  the  findings  of  the  prime  con¬ 
tractors  in  the  area  of  control  law  development  and  coding;  and 
software  development  for  these  and  other  tasks  on  PDP-11,  AN/AYK-15, 
ROLM,  EAI,  and  other  equipment. 

1.2  PERSONNEL  REQUIREMENTS 

The  minimum  qualifications  of  the  personnel  required  for  the  pro¬ 
gram  are  listed  below.  Actual  versus  planned  labor  hours  for  each  of 
the  labor  categories  are  given  in  Table  1.2-1. 


TOTAL  ACTUAL  36378  36510  34928  27256  4526  139598 


Program  Manager 

The  contractor  shall  designate  a  Program  Manager  who  will  be 
responsible  for  the  overall  administration  of  the  technical 
effort.  He  shall  devote  sufficient  attention  to  the  program  to 
assure  proper  reporting,  coordination,  and  administration  of  the 
contractual  effort.  He  shall  be  the  point  of  contact  with  the 
government  for  technical  matters. 

Systems  Integration  Engineer .  Duties  are  to  perform  integration 
of  processors,  multiplex  equipment,  control  and  displays,  support 
hardware,  and  software  and  to  determine  hardware  and  software 
requirements  for  an  aircraft  flight  simulation  facility. 

Education/Experience  Requirements.  A  Systems  Integration 
Engineer  shall  have  an  appropriate  engineering  degree  and  at 
least  five  years  of  experience  in  hardware  and  software  integra¬ 
tion.  An  appropriate  masters  degree  may  be  substituted  for  two 
years  of  experience. 

Senior  Software  Engineer .  Duties  are  to  design,  develop,  and 
maintain  software  used  in  real-time  simulation,  data  acquisition 
and  reduction,  avionics,  and  flight  control  systems. 

Education/Experience  Requirements.  A  Senior  Software  Engineer 
will  have  an  appropriate  degree  in  engineering  or  computer  sci¬ 
ence  and  a  minimum  of  four  years  experience  in  software 
management,  design,  development  and  testing.  An  appropriate  Mas¬ 
ters  Degree  may  be  substituted  for  two  years  of  experience. 
Experience  shall  include  aircraft  flight  control  systems,  redun¬ 
dancy  management,  and  simulation  development. 

System  Sof tware  Engineer .  Duties  include  design,  development, 
and  implementation  of  system  software  for  simulation 
aerodynamics/flight  control,  redundancy  management,  data  acquisi¬ 
tion  and  reduction,  and  simulation  control. 


Education/Experience  Requirements.  A  system  Software  Engineer 
shall  have  an  appropriate  degree  in  engineering  or  computer  sci¬ 
ence  and  at  least  three  years  experience  in  software  design, 
development,  and  testing.  An  appropriate  Masters  Degree  may  be 
substituted  for  one  year  of  experience . Experience  shall  include 
real-time  aircraft  simulation  and  avionics/flight  control  system 
development  and  modeling. 

Senior  Flight  Control  Systems  Engineer .  Duties  will  include  stu¬ 
dies  of  advanced  flight  control  system  architectures  and 
redundancy  management  techniques  for  digital  fly-by-wire  systems. 

Education/Experience  Requirements.  A  Flight  Control  Systems 
Engineer  shall  have  an  advanced  degree  in  Electrical  Engineering, 
Aeronautical  Engineering,  or  Mathematics  with  at  least  five  years 
of  industrial  experience  in  work  with  high  reliability  control 
systems  and  redundancy  management. 

Flight  CentXQl  Systems  Engineer .  Duties  are  to  perform  analysis 
of  flight  control  system  implementations  and  to  study  and  recom¬ 
mend  systems  to  meet  specifications. 

Education/Experience  Requirements.  A  Flight  Control  Systems 
Engineer  shall  have  an  appropriate  degree  in  engineering  and  at 
least  four  years  experience  in  design  and  analysis  of  aircraft 
flight  control  systems. 

Avionic  Systems  Engineer .  Duties  will  include  integration  of 
avionic  and  flight  control  systems  to  investigate  methods  of 
increasing  system  effectiveness,  particularly  in  the  area  of 
integrated  flight  and  fire  control. 

Education/Experience  Requirements.  An  Avionic  Systems  Engineer 
shall  have  an  appropriate  engineering  degree  and  at  least  four 
years  experience  in  avionic  systems  development.  Experience 
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shall  include  fire  control  algorithm  development,  display  require¬ 
ments,  and  system  integration. 


Circuit  Design  Engineer .  Duties  include  design  of  analog  and 
digital  interface  hardware  for  a  real-time  aircraft  simulation 
facility. 

Education/Experience  Requirements.  A  Circuit  Design  Engineer 
shall  have  a  degree  in  electrical  engineering  or  acceptable 
alternate  and  three  years  experience  in  design,  development,  and 
testing  of  analog  and  digital  hardware.  Experience  with  DEC 
PDP-11,  EAI  8400,  and  EAI  PACER  hardware  is  desirable. 

Documentation  Specialist ■  Duties  will  include  establishment  and 
maintenance  of  document  control  procedures  for  specifications, 
technical  reports,  manuals,  and  other  reference  materials  for 
advanced  development  programs. 

Education/Experience  Requirements.  Experience  in  document  con¬ 
trol  for  government  R&D  programs  is  required. 

Draftsman.  Duties  are  to  prepare  diagrams  and  engineering 
drawings  for  documentation  of  hardware  and  software  designs. 
Work  requires  practical  knowledge  of  MIL-Standards  and  drafting 
methods,  procedures,  and  techniques. 

Education/Experience.  A  Draftsman  shall  be  a  high  school  gradu¬ 
ate  with  at  least  two  years  drafting  experience. 

Technical  Typist .  Duties  include  final  typing  of  technical 
materials  insuring  proper  layout  and  assembly  of  documents  in  a 
form  suitable  for  publication. 

Education/Experience  Requirements.  A  Technical  Typist  shall  be  a 
high  school  graduate  with  at  least  two  years  experience  typing 


technical  material. 


1.3  PROGRAM  AREAS 

The  contract  work  accomplished  involved  seven  major  program 
areas,  plus  Program  Management, which  are  listed  below  with  a  brief 
description  of  each  and  a  reference  to  the  section  of  this  report 
which  describes  the  work.  The  labor  hours  applied  to  each  program 
area  are  shown  in  Table  1.3-1  at  the  end  of  this  section. 

1.3.1  Digital  Synthesis  Flight  Engineering  Facility  (Section  2.1) 

The  Digital  Synthesis  Facility  (DIGISYN)  was  developed  in  early 
1974  as  an  outgrowth  of  the  DAIS  program.  This  program  exercised 
in-flight  processors  in  a  real-time  simulation  environment.  The 
Flight  Dynamics  Laboratory  decided  to  utilize  this  concept  to  test 
actual  flight  control  system  performance  and  pilot-in-the-loop 
response.  DIGISYN  was  established  to  analyze  the  applications  of 
avionics  military  standards  to  digital  flight  control  technology.  For 
the  duration  of  the  contract,  tasks  were  performed  following  the  facility 
plan.  These  tasks  can  be  broken  down  into  the  areas  of  support  software 
(drivers,  interfaces,  corrections ) ,  flight  processor  development  (in¬ 
corporation  of  new  hardware) ,  concept  test  support  (simple  versus  full 
redundancy  management) ,  integration  and  validation  support  (flight 
control/equations  of  motion) ,  experiment  support  (iteration  rate  study) , 
and  software  documentation. 
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1.3.2  AFTI/F-16  Program  (Section  2.2) 


The  AFTI/F-16  Advanced  Development  Program  is  a  joint  USAF,  Navy, 
and  NASA  effort  aimed  at  the  development,  integration,  and  flight  test 
evaluation  of  emerging  technologies  for  improving  fighter  aircraft 
mission  effectiveness.  Major  development  thrusts  include  Digital 
Flight  Control  System,  Direct  Force  and  Weapon  Line  Control,  Pilot 
Vehicle  Interface  and  Automatic  Maneuvering  Attack  System  (AMAS) . 
Development  of  an  advanced  highly  reliable  digital  flight  control  sys¬ 
tem  (DFCS)  is  the  core  technology  building  block  for  accomplishing  the 
overall  AFTI/F-16  objectives. 

Over  the  course  of  the  program,  SCT  reviewed  and  evaluated  all 
software  documentation  produced  by  the  prime  contractor.  All  documen¬ 
tation  was  evaluated  with  a  view  to  discovering  errors, 
inconsistencies,  omissions,  or  other  significant  departures  from 
accepted  industry  standards  and  known  system  operating  characteris¬ 
tics.  Detailed  comments  and  suggestions  were  provided  to  the  Program 
Office  and  all  review  activities  were  documented  in  the  weekly  activi¬ 
ty  reports  as  well  as  the  monthly  progress  and  status  reports. 

SCT  also  provided  continuous  design  review  support  throughout  the 
program.  This  support  included  participation  in  all  system  design 
reviews,  safety  reviews,  and  numerous  technical  coordination  meetings, 
including  the  Flight  Readiness  Review,  which  were  conducted  at  General 
Dynamics  Ft.  Worth  as  well  as  at  the  Program  Office  at  WPAFB. 

In  addition  to  providing  an  independent  assessment  of  the 
software  design,  SCT  was  also  tasked  to  provide  analysis  in  support  of 
design  trade-off  studies,  and  to  permit  the  program  office  to  properly 
evaluate  potential  changes  to  the  program.  SCT  also  provided  on-site 
support  to  the  AFTI/F-16  Joint  Test  Force  (JTF)  at  Edwards  AFB.  These 
services  were  provided  starting  with  the  digital  flight  control  system 
(DFCS)  devlopment  phase  at  General  Dynamics  Fort  Worth  and  continuing 
through  actual  flight  test.  SCT  supported  this  program  in  5  distinct 
areas : 

•  Development  of  six-degree-of-f reedom  batch  simulation 
of  the  AFTI/F-16. 
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•  Systems  engineering  support  to  the  analysis,  development 
effort,  and  flight  test  of  the  DFCS  phase. 

•  Support  of  flying  qualities  test  and  evaluation  of  DFCS. 

•  Systems  engineering  support  of  development  efforts 
required  for  the  AMAS  phase. 

•  Documentation  control  and  clerical  support  to  the  JTF. 


1.3.3 


Program  (Section  2.3) 


The  emphasis  of  the  TRACS  program  is  to  demonstrate  advanced  con¬ 
trol  synthesis  applications  for  transport  aircraft  and  to  evaluate  the 
feasibility  of  crew  station  integration  concepts.  The  TRACS  program 
is  comprised  of  four  main  activities,  namely,  (1)  flight  trajectory 
investigation,  (2)  throttle/energy  management,  (3)  transport  advanced 
control  technology  and  (4)  tanker  integration  and  evaluation.  The 
flight  test  bed  to  demonstrate  the  post-1980  military  transport  mis¬ 
sion  is  the  Speckled  Trout  (C135-C)  aircraft  which  is  equipped  with  a 
digital  flight  control  system  (Sperry),  advanced  displays,  and  a 
number  of  inertial/area  navigation  (Collins)  systems.  Flight  control 
performance  improvements  have  been  demonstrated  by  incorporation  of 
digital  systems.  Analysis  and  applications  of  integrated 
throttle/flight  path  control  techniques  enable  a  pilot  or  automatic 
control  system  to  regulate  an  aircraft's  potential  and  kinetic  energy. 
The  TRACS  program  has  utilized  a  systematic  design  approach  to  systems 
integration  investigations  of  controls/displays/sensors/pilot  to  pro¬ 
vide  the  potential  for  increasing  operational  mission  performance. 

SCT  provided  support  in  the  following  areas:  Software  Acceptance 
Review,  Flight  Control  Law  Analysis,  Simulation/Validation  Facility 
Development  Support,  and  Flight  Control  Test  Support. 


1.3.4  Flight  Cwitlfll 


(Section  2.4) 


SCT  provided  support  to  the  Control  Synthesis  Branch  (AFWAL/FIGD) 
in  the  areas  of  establishing  a  software  management  methodolooy  and 
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software  tools  to  implement  this  methodology.  FIGD  is  responsible  for 
the  Flight  Control  Development  Laboratory  (FCDL)  which  provides  the 
simulation  developmental  tools  to  test  advanced  flight  technology  con¬ 
cepts. 

The  FCDL  contains  a  number  of  simulation  facilities  including  the 
LAMARS,  Multicrew  Simulator,  Fighter/Bomber  Simulator,  Crew  System 
Integration  Facility,  Flight  Control  Actuation  and  Hydraulics  System 
Facility,  and  two  in-flight  simulators  (T-33  In-Flight  Simulator  and 
the  Total  In-Flight  Simulator).  Since  particular  software  management 
requirements  vary  from  facility  to  facility,  an  in  depth  examination 
of  the  FCDL  software  development  methods  was  performed  by  talking  with 
numerous  FCDL  personnel.  The  information  collected  in  these  inter¬ 
views  was  mapped  into  requirements  to  be  addressed  in  the  ensuing 
development  of  a  software  management  methodology. 

The  software  management  methodology  which  was  developed  addressed 
all  aspects  of  software  development  from  initial  software  planning  to 
software  control  and  maintenance.  This  methodology  was  presented  in 
four  separate  volumes  of  software  standards  consisting  of  Software 
Management  Standards,  Software  Development  and  Test  Standards, 
Software  Documentation  Standards,  and  Software  Configuration  Manage¬ 
ment  Standards. 

The  second  phase  of  the  support  to  FIGD  consisted  of  development 
of  two  software  support  packages,  one  to  be  used  by  FIGD  in  control¬ 
ling  developed  software  and  the  other  to  be  used  for  tracking  FCDL 
documents.  These  software  programs  were  the  Computer  Program  Library 
Catalog  (CPLC)  Software  and  the  Documentation  Tracking  Program  (DTP) 
software . 

The  CPLC  software  helps  the  configuration  management  office  man¬ 
ager  of  FIGD  maintain  inventories  of  software  documents  and  products, 
and  status  logs  on  change  requests  and  specification  change  notices. 

Because  the  FCDL  facility  is  supported  by  a  large  number  of  manu¬ 
als  and  drawings  which  from  time  to  time  are  revised  and  have  been 
distributed  to  various  engineers,  a  need  exists  to  be  able  to  track 
the  various  documents.  The  DTP  software  provides  a  user  friendly 
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software  tool  that  will  aid  in  tracking  these  facility  documents  (man¬ 
uals,  drawings,  etc.). 


1.3.5  Control  Systems  Analysis  3LasJs_£ 

1.3. 5.1  Avionics/Flight  Control  Reconfiguration  (Section  2.5.1) 

This  study  examined  strategies  for  increasing  the  reliability  of 
integrated  control  of  flight  systems  through  reconfiguration,  particu¬ 
larly  the  concept  of  virtual  redundancy.  Virtual  redundancy,  possible 
in  highly  integrated  avionics/flight  control  system  architectures, 
involves  the  reconfiguring  of  system  resources  so  as  to  create  redun¬ 
dancy  on  demand. 

Integrated  control  of  flight  implies  a  high  degree  of  dynamic 
coupling  between  avionics  and  flight  control.  Accordingly,  much  cur¬ 
rent  emphasis  is  being  placed  on  highly  integrated,  bus-oriented 
architectures  and  bus  topologies  which  exhibit  a  high  degree  of  con¬ 
nectivity  between  flight  control  and  certain  avionics  function  (e.g., 
Integrated  Fire/Flight  Control,  Integrated  Flight/Trajectory  Control, 
Terrain  Following/Terrain  Avoidance,  etc.). 

The  Reconfiguration  Study,  along  with  its  successor  experiments, 
attempted  to  exploit  this  high  degree  of  architecture  integration  and 
bus  connectivity  to  enhance  "coverage"  and  to  recover  lost  critical 
functions . 

The  Work  accomplished  in  this  task  is  summarized  below: 

1)  Adapted  to  the  Flight  Engineering  Facility  a  multi¬ 
processor  System  Exec  from  the  DAIS  Exec  and  associated 
support  software. 

2)  Integrated  a  multiprocessor  avionics/flight  control 
architecture  with  real-time  simulation  capability. 

3)  Devised  a  workable  method  for  employing  virtual 
redundancy  and  reconfiguration  concepts  for  applications 
which  are  tolerant  of  reduced  update  rates  or  temporary 
suspension  of  output  command  (i.e.,  highly  stable  aircraft). 


4)  Established  ability  to  load  a  processor  over  1553  bus  and 
restart . 

5)  Established  ability  to  dynamically  initialize  a  processor. 

6)  Collected  preliminary  data  on  time-to-load  over  bus  and 
time- to- initialize/ recover . 

7)  Developed  all-S/W  simulation  tool  for  analyzing  alternative 
algorithms  and  architectures. 

8)  Identified  limitations  of  and  problems  with  existing 
laboratory  hardware  and  software  (Exec)  which  were  GFE  for 
this  study. 

1.3. 5. 2  Multivariable  Control  of  Wingshape  (Section  2.5.2) 

Demonstration  of  the  mission-adaptive  wing  (MAW)  technology,  also 
called  "smooth  variable  camber"  (SVC),  is  an  objective  of  the  Air 
Force's  performance,  control,  and  mission  effectiveness  benefits  for 
an  aircraft  with  a  smooth  variable  camber  wing  will  be  demonstrated  by 
the  AFTI  F-lll  airplane.  The  design  objective  is  to  use  the  variable 
wing  camber  to  optimize  the  wing's  aerodynamic  efficiency  over  a 
broader  speed  range  and  to  provide  additional  control  devices.  Under 
the  current  AFTI  F-lll  contract,  two  approaches  to  automatically  con¬ 
trol  wing  camber  are  being  investigated:  "preprogrammed"  and  "self 

optimizing".  However,  identified  weaknesses  of  each  of  these  control 
modes  suggest  that  to  enable  SVC  benefit  realization,  research  and 
development  in  this  area  should  continue. 

Optimum  camber  selection  is  a  multivariable  control  problem  and 
may  require  use  of  modern  control  techniques  for  satisfactory  perfor¬ 
mance.  Prior  to  the  initiation  of  the  program  described  in  this 
report,  the  available  technical  data  base  was  inadequate  to  support  a 
multivariable  control  design  implementation  within  the  AFTI  F-lll  MAW 
development  program  schedule.  In  response  to  this  deficiency,  the 
Flight  Control  Division  of  the  Flight  Dynamics  Laboratory  formulated 
an  exploratory  study  to  develop  the  modern  control  design  technology 
for  aircraft  applications.  Objectives  of  this  technology  development 
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are  listed  as  follows: 


o  Evaluate  the  application  of  modern  control  design 
techniques  to  the  synthesis  of  complex  aircraft 
control  laws. 

o  Define  multifunctional/multivariable  control  law 
structures  which  are  adapted  to  advanced  aircraft 
mission  requirements. 

o  Assess  the  design  impact  of  multivariable/multi¬ 
functional  control  systems. 

A  summary  of  the  work  accomplished  in  this  task  is  given  below: 

1)  Developed  the  design  objectives  and  requirements 
for  the  flight  control  system  of  an  aircraft  that 
integrates  smooth  wing  camber  control  with 
conventional  aircraft  controls. 

2)  Developed  a  conceptual  design  of  a  multivariable/ 
multimode  flight  control  system. 

3)  Developed  an  overview  of  multivariable  design 
techniques  and  a  detailed  description  of  linear 
quadratic  synthesis  methods. 

4)  Prepared  a  technology  assessment  of  the  proposed 
flight  control  system  and  recommendations  for  a 
research  and  development  program  that  addresses 
these  issues. 

1.3. 5. 3  FIREBOLT  Target  Drone  Analysis,  Simulation  and  Flight 
Test  Support  (Section  2.5.3) 

This  task  was  undertaken  to  develop  a  simulation  which  provides 
Eglin  Air  Force  Base  Armament  Division  an  in-house,  quick  reaction 
capability  to  evaluate  the  FIREBOLT  performance  and  stability  indepen¬ 
dent  of  the  prime  FIREBOLT  contractor's  assessments  and  to  provide  a 
tool  for  the  FIREBOLT  flight  test  program. 


12 


I 


I 


. 

h 

. 


The  main  objectives  of  this  project  were  to: 

1)  Develop,  update,  maintain  and  validate  the  six-degrees- 
of-freedom  (6D0F)  digital  simulation.  This  included 

all  design  changes  to  the  FIREBOLT  vehicle  made  by  Teledyne 
Ryan  or  the  Air  Force  and  included  model  updates  based  on 
post-flight  test  analysis.  All  updates  were  documented 
and  provided  to  the  Air  Force.  Validation  of  the 
simulation  was  accomplished  by  matching  simulation 
performance  characteristics  to  flight  test  results.  The 
6  DOF  simulation  was  written  in  FORTRAN  IV  and  subsequently 
modified  to  FORTRAN  V,  and  is  compatible  with  the  CDC  6600 
at  Eglin  Air  Force  Base. 

2)  Provide  an  independent  assessment  of  the  FIREBOLT  flight 
control  system  design,  including  design  changes  and 
modifications.  Also  provide  written  and  oral  comments  on 
FIREBOLT  contract  data  items  in  the  areas  of: 

o  Flight  control  system 

•  Aerodynamics 

•  Test  plans,  reports,  and  analysis. 

3)  Provide  pre-  and  post-flight  test  analyses  on  each  flight 
test  vehicle  to  include,  but  not  be  limited  to,  flight 
performance,  profile,  sensitivity  analysis,  diagnostic 
analysis  of  problems  and  recommendations. 

4)  Provide  operational  instructions  to  Air  Force  personnel 
in  the  use  of  the  6D0F  simulation. 

1.3.6  Control /Pi splay  Development  (Section  2.6) 

SCT  has  been  supporting  the  Crew  Systems  Integration  Branch  of 
the  Air  Force  Wright  Aeronautics  Laboratories  ( AFWAL/FIGR)  in  the 
development  of  control  arid  display  technology.  The  digital  synthesis 
simulator  (DIGISYN)  was  used  to  investigate  the  impact  of  digital 
avionics  information  on  pilot/aircraft  performance  and  effectiveness. 
The  support  tasks  to  FIGR  have  included: 

-  2-D  Display  Software  Support:  Examine  the  feasibility  of 
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integrating  altitude,  lateral  performance,  predicted 
lateral  performance  and  situation  information  on  a  single 
display  surface. 

-  Color  Terrain  Display  System  Support:  Investigate  the 
feasibility  of  using  computer  image  generation  techniques 
to  display  terrain  and  cultural  features.  Definitize 
requirements  for  achieving  this  capability  on  the  DIGISYN 
and/or  recommend  equipment  and  software  needed  to  achieve 
this  display  in  a  real-time  simulation  environment. 

-  Speech  Applications  (SPAM)  Experiment  Support:  Investigate 
voice  activation  and  control  of  aircraft  displays. 

-  Flat  Panel  Display  Support:  Test  the  possibility  of  using 
flat-panel  LED  multimode  matrix  displays  as  a  multi  purpose 
display  to  present  real-time  flight  parameter  and  system 
status  information. 

-  Pictorial  Emergency  Procedures/Speech  Interaction  Support 

(PEPSI) :  Compare  different  methods  of  communicating 

emergency  procedures  to  the  pilot.  The  methods  compared 
were:  a  pictorial  display,  an  alphanumeric  display,  and  an 
aural  warning/procedure  checklist. 

-  Microprocessor  Application  of  Graphics  and  Interface 
Communication  (MAGIC):  Development  of  a  "dynamic  mockup" , 
driven  by  microprocessors < which  can  be  used  for  testing 
possible  applications  of  color  flight  displays  and  voice 
technology  for  a  future  advanced  tactical  fighter. 

Systems  Control  Technology,  Inc.  provided  systems  and  software 
development  expertise  necessary  to  implement  and  conduct  the  above 
mentioned  studies/support  tasks.  This  support  included: 

-  systems  and  software  functional  and  interface 
requirements  definition 

-  Development  of  software  interface  drivers 

-  Generation  of  tailored  operating  systems 

-  Design,  development,  test  and  documentation  of 
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software  modules  to  meet  software  requirements 

-  Modification  of  existing  DIGISYN  software  to  meet 
software  requirements 

-  Integration  and  checkout  of  experiment  software  modules 

-  Experiment  support  to  aid  in  conducting  experiments,  and 
gathering  and  reducing  data. 

During  these  support  efforts,  software  design  documents  and  code  were 
prepared  and  delivered  to  AFWAL/FIGR  to  provide  continuity  and  control 
of  all  support  tools. 

1.3.7  AFTI/F-111  Program 

The  Advanced  Fighter  Technology  Integration  (AFTI)  F-lll  Program 
consists  of  two  phases.  The  first  phase  addresses  the  design  and 
development  of  a  variable  camber  (VC)  mission  adaptive  wing  (MAW)  and 
includes  a  flight  test  program.  Testing  of  the  MAW  will  be  performed 
using  a  manual  pilot-controlled  fly-by-wire  system  for  setting  MAW 
leading  and  trailing  edge  deflections.  This  manual  system  provides 
for  evaluation  of  general  quasi-static  aerodynamic  performance  and  for 
developing  flight  control  parameters. 

Phase  two  of  the  AFTI/F-111  Program  addresses  the  design  and 
development  of  a  modification  to  incorporate  an  automatic  flight  con¬ 
trol  system  (AFCS)  capability  for  the  MAW  that  is  compatible  with  the 
manual  control  system.  A  second  flight  test  program  is  planned  to 
evaluate  the  MAW  with  automatic  controls  and  demonstrate  the  perfor¬ 
mance  benefits  provided  by  the  AFCS  functions. 

SCT  has  been  providing  systems  and  software  support  to  AFWAL/FIMS 
for  the  AFTI/F-111  MAW  program.  This  support  has  occurred  in  three 
areas:  software  management,  simulation  support,  and  control  system 
design. 

SCT  has  provided  software  support  to  address  the  management 
aspects  of  the  AFTI/F-111  MAW  Manual  Flight  Control  System  (MFCS)  and 
Automatic  Flight  Control  System  (AFCS)  software  development.  Support 
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has  included:  review  of  all  developing  contractor  software  documents 
and  many  system  documents,  providing  document  review  comments  to  the 
Air  Force/  active  participation  in  all  system  and  software  design 
reviews  of  the  MAW  program,  and  working  closely  with  the  Air  Force 
and  NASA  in  performing  a  critical  review  of  the  contractor  software 
development  plan  to  provide  guidance  in  the  areas  of  software  documen¬ 
tation,  software  configuration  control,  and  software  development 
milestone  reviews. 

SCT  has  also  provided  simulation  development  support  at 
NASA/Dryden.  This  support  consisted  of  detailed  review  of  system  and 
software  requirements  for  the  MAW  MFCS  and  AFCS,  and  assistance  in 
implementation  of  these  requirements  into  a  functional  simulation  of 
the  MAW  system. 

SCT  also  performed  a  study  to  evaluate  an  alternative  approach  to 
controlling  wingshape  design.  The  objectives  of  the  study  were  to 
define  potential  multivariable  control  law  structures  which  are  suit¬ 
able  for  active  wingshape  control,  recommend  design  and  algorithm 
implementation  techniques,  and  assess  the  design  impact  of  a  multivar¬ 
iable  active  wingshape  control  system. 

1.4  CONTRACT  DELIVERABLES 

Over  the  course  of  the  contract,  SCT  delivered  more  than  15,000 
pages  of  documentation,  including  54  progress  reports  and  more  than 
200  specifications,  technical  memoranda,  technical  reports,  and  the 
software  documents  listed  in  Table  1.4-1  at  the  end  of  this  Section. 

1.5  CONCLUSIONS  AND  RECOMMENDATIONS  SUMMARY 

Digital  Synthesis  Facility 

The  Digital  Synthesis  Flight  Engineering  Facility  has  provided  a 
means  to  obtain  hands-on  experience  in  the  application  and  use  of  con¬ 
trol  systems  and  applicable  software  standards.  The  experience  gained 
in  the  use  of  the  facility  implies  a  strong  need  for  facility  capabil- 
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ities  to  emulate  system  designs.  A  second-generation  Digital 
Synthesis  Facility  should  have  the  capability  to  address  critical 
flight  control  technology  issues  in  the  areas  of  system  requirements 
specifications,  flight  control  systems  test  and  evaluation,  DFCS 
design,  redundancy  management,  control  law  design,  and  handling  quali¬ 
ty  criteria. 

AFTI/F-16  Program 

Independent  contractor  support  for  a  program  of  this  type  is 
extremely  important  in  the  areas  of  documentation  review;  software 
design  review,  analysis,  and  V&V  audit;  redundancy  management; 
simulation  and  analysis;  flight  test  planning;  documentation 
control;  and  flight  test  data  analysis.  The  need  for  independent 
analysis  is  even  more  acute  during  the  AMAS  phase  of  the  program 
because  of  the  additional  complexity  which  arises  from  several  new 
techniques  which  are  to  be  integrated  and  evaluated  simultaneously. 


Transport 


The  TRACS  program  has  utilized  a  systematic  design  approach  to 
system  integration  investigations  of  controls/displays/sensors/pilot 

to  provide  the  potential  for  increasing  operational  mission  performance. 


Adherence  to  desired  standards  for  software  development,  manage¬ 


ment,  and  configuration  control  in  a  simulation  facility  with  many 
diverse  and  complex  requirements  is  a  difficult  goal.  The  software 


management  methodology  developed  by  SCT  in  concert  with  FIGD  should 
enable  attainment  of  that  goal,  but  requires  commitment  by  FIGD  man¬ 


agement  and  acceptance  by  the  work  force. 


The  reconfiguration  study  provided  an  initial  step  in  the 
determination  of  the  feasibility  of  the  concept  of  virtual  redundancy 
and  reconfiguration  as  a  means  of  increasing  the  reliability  of 
integrated  avionics/flight  control  systems,  and  identified  future 
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study  requirements. 


Multivariable  Control  of  Winoshape 

Modern  control  design  techniques  are  well-suited  for  the  develop¬ 
ment  of  complex  control  systems  such  as  the  mission  adaptive  wing. 
There  are  a  number  of  technology/design  issues  which  still  need  to  be 
addressed  in  order  to  quantify  the  benefits  of  an  optimal  performance 
seeking  flight  control  system. 

FIREBQLT  Target  Hipne 

The  simulation,  developed  by  SCT,  provides  a  quick-reaction  capa¬ 
bility  to  evaluate  the  FIREBOLT's  performance  and  stability. 


Advanced  Control/Display  Concepts 

The  support  contractor's  role  in  the  work  being  performed  not 
only  encompassed  software  development,  but  also  involved  the  areas  of 
systems  analysis  and  systems  engineering.  In  many  cases,  the  level  of 
support  needed  for  a  simulation  development  task  included  extensive 
knowledge  of  the  hardware  being  used  in  the  effort  as  well  as  an 
understanding  of  the  experimental  design  and  statistical  techniques 
being  used  in  the  study. 

afti/f-111  Ripgxam 

With  the  current  trends  in  computer  hardware,  software  develop¬ 
ment  costs  are  becoming  the  major  portion  in  the  acquisition  cost  of 
systems  involving  hardware  and  software.  To  reduce  these  costs 
software  management  must  work  toward  the  following  objectives; 

-  Reduce  resource  expenditures  in  software  development. 

-  Improve  software  development  resource  estimating. 

-  Avoid  duplicate  development  efforts. 

-  Improve  quality  of  software. 

-  Reduce  software  maintenance  efforts. 


In  future  development  efforts,  the 


Air  Force  should  initially 


make  certain  that  the  development  contractor  has  a  well-defined, 
phased  software  management  approach  with  scheduled  review  milestones. 
As  the  software  development  progresses,  the  Air  Force  should  actively 
participate  in  the  software  review  process  to  assure  that  initial 
development  plans  are  being  met  and  that  these  plans  are  still  aligned 
with  final  design  goals. 

Management  Lessons  Learned 

1)  Task  instruction  procedures  were  very  efficient  and 
provided  adequate  flexibility  for  quick  response  to 
changing  requirements. 

2)  The  nature  of  the  work  assigned  required  a  higher 
percentage  of  senior  technical  personnel  than  originally 
planned. 

3)  Program  management  and  clerical  support  required  a  higher 
percentage  of  the  total  effort  than  originally  estimated 
due  to  the  diversity  of  the  technical  tasks. 

4)  The  assignment  of  individual  project  managers  in  each  of 
the  major  program  areas  provided  the  necessary  diverse 
technical  management  expertise,  and  enhanced  the  day-to-day 
technical  interface  with  the  corresponding  Air  Force  Project 
Engineers. 

5)  The  utilization  of  sub-contractors  and  consultants  allowed 
quick  reaction  to  unforseen  special  technical  support 
requirements  on  an  ad  hoc  basis,  and  minimized  the  effects 
of  work  load  fluctuations. 

6)  Continuity  in  assigned  tasks  enhanced  "corporate  memory" 
and  minimized  start-up  effort  on  new  tasks. 

7)  Computer  time  and  travel  requirements  in  support  of  the 
Advanced  Development  Programs  were  four  times  that  originally 
estimated. 
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2.1  DIGITAL  SYNTHESIS  FACILITY 


2.1.1  Facility  Background  and  Goals 

The  Digital  Synthesis  Facility  (DIGISYN)  was  developed  in  early 
1974  as  an  outgrowth  of  the  DAIS  program.  This  program  exercised 
on-flight  processors  in  a  real-time  simulation  environment.  The 
Flight  Dynamics  Laboratory  decided  to  utilize  this  concept  to  test 
actual  flight  control  system  performance  and  pilot-in-the-loop 
response.  DIGISYN  was  established  to  analyze  the  application  of 
avionics  military  standards  to  digital  flight  control  technology. 
Some  of  the  military  standards  to  be  analyzed  recently  within  DIGISYN 
are  the  1553  aircraft  multiplex  bus  data  standard,  the  1750  minicom¬ 
puter  instruction  set  architecture  standard, and  the  1589  JOVIAL  higher 
order  language  standard.  In  addition,  flight  safety,  various  archi¬ 
tectures,  and  integrated  systems  issues  have  been  investigated. 

Figure  2-1  presents  the  major  milestones  accomplished  by  DIGISYN 
since  1974.  Recent  highlights  include  the  design  and  development  of  a 
flight  control  specification  in  JOVIAL  in  February  1980;  the 
integration  and  validation  of  a  single  remote  terminal/flight 
control/equations  of  motion  system  in  February  1981;  the  integration 
of  a  simplex  flight  control  system  in  May  1982;  and  the  integration 
of  a  quad  redundant  flight  control  system  in  November  1982.  (The 
quad  redundant  FCS  did  not  operate  correctly,  due  to  unresolved 
hardware  and  software  problems). 


2.1.2  Facil ity  Description 

The  DIGISYN,  shown  in  Figure  2-2,  comprises  four  PDP-lls;  a 
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ilestones  Accomplished  by  DIGISYN 


rack  of  aircraft  processors  containing  a  quad  system  of  AN/AYK-15S, 
Bus  Control  Interface  Units  (BCIUs) ,  Voter  Monitors,  Midship  Remote 
Terminals  (RTs) ,  and  Aft  RTs;  a  mock  cockpit  facility  for  testing 
pilot-in-the  -  loop  responses  and  a  rack  containing  the  avionics 
AN/AYK-15  and  BCIU,  the  avionics  RT,  the  forward  RTs,  and  a  cockpit 
test  stand. 

DIGISYN  has  developed  a  quad-channel  flight  control  system  which 
utilizes  the  hardware  components.  Figure  2-3  presents  the  quad  chan¬ 
nel  system  and  the  hardware  interfaces  between  the  components. 


2.1.3 


Plans 


DIGISYN  recognized  the  need  for  a  high-level  integration  program 
utilizing  a  real-time  simulation  test  bed.  Of  fundamental  concern  to 
the  organization  were  flight  control  systems,  pursuit  of  new  architec¬ 
tures  and  the  evaluation  of  military  standards. 

The  plan  was  to  acquire  the  hardware  and  software  necessary  to 
nerform  the  evaluations  and  document  the  results. 

2.1.4  Work  Accomplished 

For  the  duration  of  the  contract,  tasks  were  performed  following 
the  facility  plan.  These  tasks  can  be  broken  down  into  the  areas  of 
support  software  (drivers,  interfaces,  corrections),  flight  processor 
development  (incorporation  of  new  hardware),  concept  test  support 
(simple  versus  full  redundancy  management) ,  integration  and  validation 
support  (flight  control/equations  of  motion),  experiment  support 
(iteration  rate  study) ,  and  software  documentation. 

2. 1.4.1  Support  Software  Development 


A  variety  of  tasks  were  accomplished  under  this  heading.  All 
Equations  of  Motion  (EOM)  software  modifications  were  considered  sup¬ 
port  software  since  the  initial  software  was  already  written  and 
documented  at  the  inception  of  this  contract.  Those  tasks  performed 
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Figure  2-3  Quad-Channel  Flight  Control  System 


were : 


•  Designed  and  devloped  an  EOM/terrain  board  interface 
driver  to  allow  the  real-time  control  of  the  terrain 
board  cameras  as  well  as  the  protocol  and  handshake 
functions. 

•  Adjustment  of  scale  factors  to  decrease  the  number 
of  arithmetic  overflows. 

•  Implemented  a  programmable  function  generator  which 
can  produce  a  step,  doublet,  or  square  waveform  of 
selectable  amplitude  and  frequency. 

•  Correction  of  the  EOM  display  page  4  time  overflow 
problem. 

•  Modified  the  EOM  software  to  output  all  variables  to 
the  flight  control  laws  at  an  80  Hertz  rate. 

0  EOM  4-Port  Memory  Incorporation — This  task  has  not  been 
completed.  Many  problems  have  been  identified  and 
corrected  but  the  4-port  memory  is  still  not  operational. 

A  simple  driver  to  handle  the  4-port  memory  based  on 
a  working  RT-11  version  was  not  completed  at  the  end  of 
this  contract. 

•  Performed  an  EOM  global  variable  analysis,  which  identified 
all  source  files  in  the  EOM,  the  names  of  subroutines 
invoked,  the  read/write  access  type  of  all  global  variables 
and  a  list  of  the  general  registers  and  their  access  type. 

0  Added  the  necessary  software  to  incorporate  the  quad 
channel  A/D  software. 

Additional  support  tasks  were  to: 

0  Provide  file  transfer  capability  from  the  DECsystem-10 
to  the  DIGISYN  PDP  11/40  processor.  This  involved 
software  and  hardware  verification. 

0  Provide  a  software  and  documentation  configuration 
control  plan  for  DIGISYN  which  includes  resource 
control  for  disks  and  tapes  and  disk  maintenance 
procedures . 
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•  Reconfigure  and  rebuild  the  RSX-11M  system  disk, 
whenever  necessary  (such  as  bad  block  detection,  new 
hardware,  etc. ) . 

•  Design  of  a  Performance,  Monitor  and  Control  (PMC) 
system  for  the  PDP-11/40  for  evaluation  of  the  single 
channel  flight  control  system. 

•  Convert  URT  software  to  RSX-11M.  This  conversion 
involved  a  new  sysgen,  the  definition  of  the  URT 
software  to  be  converted,  investigation  of  handling 
interrupt  processing,  virtual  address  conversion  to  a 
physical  address,  and  a  new  display  format. 

2. 1.4. 2  Flight  Processor  Computer  Program  Development 

This  area  encompasses  all  the  software  written  to  be  run  on  the 
AN/AYK-15s.  The  original  flight  control  laws  for  the  A-7D  were  writ¬ 
ten  at  the  inception  of  this  contract.  Their  validation  is  referred 
to  in  Section  2. 1.4. 4.  Tasks  performed  were: 

•  IBM/BCIU  Design  and  Development — This  software  provided 
an  interface  between  the  AN/AYK-15  processors  and 

the  BCIU  in  the  DAIS  interface  format.  All  handshake 
and  scheduling  operations  were  also  controlled. 

•  Developed  a  library  of  I/O  routines  using  J0VIA1  (BCIU, 
AN/AYK-15  and  RT,  initialization,  conversion  of  decimal 
to  binary,  conversion  of  binary  data  to  hexadecimal, 
character  string  handler). 

•  Redundancy  Management  (RM)  Software  Design  and  Develop¬ 
ment — This  software  was  designed  to  handle  failed  signals 
and  permit  pilot  recycling. 

•  Correct  the  Iteration  Rate — The  flight  control  law  (FCL) 
software  was  determined  to  be  running  at  an  8-Hertz  rate 
instead  of  the  correct  80-Hertz  rate. 

•  Power-Down/Power-Up  Capability--Sof tware  was  written  to 
enable  recoverability  of  the  AN/AYK-15  software  after 

a  Power-Down/Power-Up  sequence. 


< 


I 


1 


I 


•  COMPOOL  Incorporation — The  JOVIAL  software  was  reorganized 
to  utilize  the  COMPOOL  features  of  JOVIAL. 

•  New  Mux  Driver  Design  and  Development--This  software 
incorporated  a  three  remote  terminal  system  as  well  as 
a  serial  activity  processor  module. 

•  Forward  RT  Incorporation — The  JOVIAL  software  was 
modified  to  accept  input  data  from  the  forward  RT. 

•  Mid  RT  Incorporation — The  JOVIAL  software  was  modified 
to  accept  input  data  from  the  mid  RT. 

•  Voter/Monitor  Incorporation — The  JOVIAL  software  was 
modified  to  utilize  the  hardware  voter/monitors  when 
outputting  data  to  the  EOM. 

•  Mode  Switch  Selection  Incorporation — The  JOVIAL  software 
was  modified  to  allow  a  switch  depression  from  the 
multi-function  keyboard  (MFK)  to  be  read  by  the  avionics 
RT  and  passed  via  the  AFCI  to  the  AN/AYK-15. 

•  Channel  Selection  Incorporation — The  JOVIAL  software 

was  modified  to  allow  selection  of  either  single-  or  quad- 
channel  output  processing. 

®  Stair  Step  for  Single  Channel — The  JOVIAL  software  was 
modified  to  output  increasing  values  ranging  from  -1024 
to  1024  for  each  minor  frame  in  place  of  the  old  sync 
signal.  This  allowed  quick  visual  verification  on  the 
strip  chart  recorder  that  the  minor  frame  software  was 
being  executed. 

•  J73/I  to  JOVIAL  Conversion — The  J73/I  software  was 
converted  to  use  the  JOVIAL  compiler  which  is  the  MIL-STD- 
1589B  implementation. 

2. I. 4. 3  Concept  Test  Support 


|  Tasks  in  this  area  are  those  which  were  performed  to  evaluate  a 

theory  or  concept;  i.e.,  will  this  idea  work  and  the  software  still 
be  able  to  run  an  80  Hertz  rate? 
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•  Integrate  a  Flight  Control  Skew  Control  Unit  (FSCU), 
a  Simulation  Subsystem  Integration  Unit  (SS1U),  and 
a  Bus  Monitor  Unit  (BMU)  to  provide  the  capability 
to  evaluate  the  operation  of  a  quad-redundant, 
asynchronous  flight  control  system.  The  FSCU  controls 
the  timing  of  the  flight  control  processors  for  the 
escalation  of  the  effect  of  asynchronous  operation  on 
redundancy  management  and  system  reliability.  The 
SSIU  provides  quad-redundant  sensor  inputs  to  the 
processors  through  the  RTs. 

•  A  simplified  redundancy  management  module  was  written 
and  incorporated  into  the  Flight  Control  Law  software. 

A  simplified  version  was  selected  to  be  integrated  to 
ensure  that  there  would  be  no  timing  problems  in  the 
AN/AYK-15 . 

•  A  full  redundancy  management  module  was  written  and 
incorporated  into  the  Flight  Control  Law  software. 

This  version  is  based  on  the  design  by  Dr.  Charles 
Slivinsky . 

2. 1.4. 4  Integration  and  Validation  Support 

The  tasks  in  this  area  integrated  the  various  subsystems  (flight 
(control  and  EOM)  and  then  validated  the  results. 

•  Hardware  interface  verification  between  the  AN/AYK-15 

and  the  PDP-11/34.  This  involved  testing  and  verification 
of  all  scale  factors. 

•  A  trace  procedure  was  written  and  coded  to  aid  in 
integration. 

•  Stand-Alone  validation  of  the  singl e -channel  Flight 
Control  Law  Software  (FCLSW)  where  test  procedures  were 
developed  and  executed.  Results  were  then  validated 
based  on  predicted  outcomes  (see  Figure  2-4) 

•  Static  checkout  of  the  single  FCLSW  and  the  EOM, 
which  involved  running  both  systems  and  verifying  that 
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conditions  remained  stable. 

•  Dynamic  checkout  of  the  single  channel  FCLSW  and  the 
EOM,  which  involved  running  both  systems  with  various 
input  signals  and  then  validating  results  (see  Figure  2-5) 

•  Rehost  of  Avionics  Laboratory  diagnostics  software 
for  the  RTs,  URT,  and  BMU  to  the  DIGISYN  processor. 

•  Static  Checkout  of  the  quad -channel  FCLSW  and 

the  EOM.  The  tests  conducted  were  a  subset  of  those 
run  for  the  single -channel  static  checkout.  All 
flight  control  RTs  were  utilized  as  well  as  the  avionics 
RT. 

•  Dynamic  checkout  of  the  quad-channel  FCLSW  and  the 
EOM.  Again  the  tests  conducted  were  a  subset  of  those 
run  for  the  single-channel  dynamic  checkout. 

2. 1.4. 5  Experiment  Support 

Once  the  hardware  and  software  for  the  single-channel  system  was 
validated,  various  experiments  were  designed  and  discussed  as  to  their 
flight  control  and/or  military  standard  significance.  After  it  was 
determined  which  experiments  were  to  be  performed,  software  was  writ¬ 
ten  and  hardware  developed  as  necessary,  to  record  the  results. 

2. 1.4. 5.1  Skew  Studies 


The  Flight  Control  Law/EOM  Processor  Skew  Studies  investigated 
the  effect  of  varying  the  skew  between  the  EOM  Processor  and  the 
AN/AYK-15.  The  objective  was  to  determine  the  impact,  if  any,  of  pro¬ 
cessor  skew  (asynchronism)  on  the  integrety  of  bus  transmissions  and 
flight  control  law  performance.  This  experiment  was  an  essential  step 
n.  the  Digital  Synthesis  facility  development  since  the  concept  of  quad 
redundant  AN/AYK-15s  rely  on  asynchronous  operation. 

Experiment  support  involved  the  establishment  of  a  synchroniza¬ 
tion  1 1 1 iC  between  the  AN/AYK-15  and  the  PDP-11/34  and  the  development 
of  a  hardware  board  to  bias  the  clocks  between  the  two  processors. 


Figure  2-5  Dynamic  Single-Channel  FCLSli  Validation 


2. 1.4. 5. 2  Iteration  Rate  Studies 


The  processor  iteration  rate  studies  investigated  the  effect  of 
varying  the  iteration  rates  of  both  the  flight  control  laws 
(AN/AYK-15)  and  the  EOM  (PDP-11/34).  The  objective  was  to  determine 
the  impact  on  control  law  performance.  This  experiment  provided 
information  on  any  spare  time  available  to  accommodate  any  additional 
code.  It  also  provided  information  as  to  how  much  faster  the  EOM  must 
be  executed  relative  to  the  control  laws  so  as  to  appear  "continuous" 
to  the  asynchronous  sampling  channels. 

Experiment  support  involved  developing  software  to  measure  spare 
duty  cycle  and  execution  times  for  various  phases  of  control  law  pro¬ 
cessing  . 

2. 1.4. 6  Software  Development  and  Documentation  Summary 

Table  2-1  summarizes  the  software  development  efforts  undertaken 
over  the  duration  of  the  Integrated  Control  System  Engineering  Support 

contract . 

2.1.5  Technology  Assessment 
2. 1.5.1  [''light  Control  Issues 
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Multiplex 

•  Verification  of  flight  control  performance  with  a 
MIL-STD-1553A  multiplex  data  bus. 

•  Investigate  potential  problems  with  latent,  single¬ 
point  or  propagated  failures. 

e  Investigate  efficiency  of  information  transfer. 

•  Evaluate  ease-of -reconfiguration. 

•  Investigate  self-test  capabilities,  reliability, 
failure  isolation,  optimal  modular  construction, 
bus/bus  interface  problems,  and  electromagnetic 
interference  susceptibility. 

•  Study  multiplex  bus  loading  requirements. 

Flight  Control  Software 

«  Demonstrate  efficiencies  of  modular  software  and 
higher  order  language. 

•  Evaluate  trade-offs  for  various  executive  structures. 

•  Evaluate  time/memory  trade-offs  of  macrostatements 
versus  subroutines. 

®  Evaluate  to  what  extent  higher  order  language  is  feasible. 

•  Investigate  which  commands/instructions  in  JOVIAL  are  not 
acceptable  for  flight  control. 

•  Evaluate  improvements  in  development  time  expected  for 
changes  and  new  applications  with  modular  software. 

a  Investigate  methods  for  avoiding  single-point  software 
failures. 

•  Investigate  adequacy  of  the  compiler  with  respect  to 
efficiency  and  error  processing. 

•  Evaluate  performance  penalties  and  improvements  resulting 
from  use  of  AN/AYK-15  processors. 

©  Evaluate  what  hardware  fatures  of  AN/AYK-15  are  most 
beneficial  for  flight  control. 

©  Evaluate  the  extent  of  performance  degradation  resulting  from 
digitization  of  control  laws. 
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2. 1.5. 2  Analysis  and  Equipment  Recommendations 


2. 1.5. 2.1  Demo  A1  Synchronizing  Implementation  Test 

The  Demo  Al  Synchronizing  Implementation  Test  demonstrated  that 
the  Flight  Control  Laws  (FCL)  on  the  AN/AYK-15  and  the  Equations  of 
Motion  ( EOM)  on  the  PDP-11/34  (see  Figure  2-6)  are  synchronized 
together  and  can  be  skewed  relative  to  each  other  by  as  much  as  12.5 
msec  The  AN/AYK-15  processor  is  the  controlling  device. 

The  primary  objective  of  this  test  was  to  demonstrate  the  follow¬ 
ing  functional  capabilites: 

•  Provide  synchronization  between  the  FCL  and  EOM 
utilizing  a  spare  D/A  output  channel  on  the  RT. 

•  Provide  software  programmable  skew  control  between 
the  FCL  and  the  EOM. 

•  Provide  asynchronous  operation  of  the  EOM  relative 
to  the  FCL,  utilizing  the  PDP-11/34  initial  clock. 

Test  #1  was  conducted  with  no  skewing,  and  there  was  an 

approximate  12.5  msec  delay  due  to  the  EOM  execution  time. 
Consequently,  the  EOM  was  half  a  cycle  behind  the  FCL.  This  situation 

was  remedied  by  having  the  AN/AYK-15  send  the  pitch,  roll,  and  yaw 

displacements  first,  and  the  sync  signal  last.  In  this  manner,  + he 
EOM  already  had  the  FCL  outputs  when  the  sync  signal  arrives.  Also  in 
Test  #1  we  noted  that  PITDSP  does  lag  PSFAV  by  approximately  5  msec. 
We  also  observed  that  all  EOM  outputs  lag  PITDSP  (EOM  input)  by  a  cer¬ 
tain  amount  of  time.  The  delay  is  due  to  EOM  execution  time  in 

combination  with  a  programmed  0.05  second  lag  although  PITDSP  is  in 
sync. 

Test  #2  was  performed  with  the  addition  of  a  skew  (time  delay)  to 
the  received  EOM  SYNC  signal  of  12.5  msec  (maximum  delay).  In  combi¬ 
nation  with  the  12.5  msec  delay  due  to  the  EOM  execution  time,  the 
signal  response  should  have  been,  and  was,  25  msec.  PITDSP  was  still 
in  sync,  just  as  it  was  in  Test  #1. 

Test  #3  graphically  showed  that  when  the  FCL  is  halted,  the  EOM 
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Figure  2-6  Austere  Single  Channel  Flight  Control  Simulation  -  Issues 


is  halted  due  to  lack  of  sync  signal. 

In  conclusion,  all  of  the  test  objectives  of  Demo  Al  were 
achieved.  The  only  inconsistency  between  the  predefined  test  objec¬ 
tives  and  the  results  was  the  12.5-msec  delay  due  to  the  EOM  execution 
time  discussed  above. 

2. 1.5. 2. 2  Demo  A2  FCL  and  EOM  Closure  and  Stability  Test 

The  FCL  and  EOM  Closure  and  Stability  Test  demonstrated  a  stable 
closed-loop  system  with  the  Flight  Control  Law  (FCL)  on  the  AN/AYK-15 
and  the  equations  of  Motion  (EOM)  on  the  PDP-11/34.  The  primary 
objective  of  this  test  was  to  demonstrate  the  following  functional 
capabilites : 

•  Stable  EOM  Subsystem  with  no  integer  overflows 
occurring 

•  Stable  FCL  Subsystem 

•  Stable  closed-loop  EOM/FCL  system. 

To  accomplish  the  preceding  objectives,  the  following  test 
approach  was  used: 

A.  Static  Test  with  Flight  Control  "off"  (Demo  A2.1) — 

The  purpose  of  the  static  test  was  to  ensure  that 
the  closed  loop  EOM/FCL  system  will  maintain  its 
stability  and  not  drift  significantly  from  the  aircraft 
model  trim  condition  when  no  control  inputs  are  applied 
to  the  system.  This  test  was  conducted  using  data 

set  0 . 

B.  Static  Test  with  Flight  Control  "on"  (Demo  A2.2) — 

This  test  was  run  to  verify  that  the  system  would 
still  maintain  a  relatively  steady  state  with 
flight  control  "on". 

C.  General  Dynamic  Test  (Demo  A2.3)--The  purpose  of  this 
(.ynamic  test  was  to  demonstrate  that  the  flight  control 
laws  and  the  EOM  both  respond  to  pilot  stick  inputs 

in  a  reasonable  manner. 

The  system  configuration  used  for  the  FCL  and  EOM  Closure  and 
stability  Test  is  depicted  in  Figure  2-7. 

Test  #1  (Demo  A2.1)  was  conducted  as  a  static  test,  running 
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closed-loop  with  the  FCL  oif.  The  test  results  showed  that  the 
closed-loop  EOM/FCL  system  is  stable.  The  pitch,  roll,  and  yaw  rates 
were  all  in  the  noise  level  about  zero.  Pitch  altitude  oscillated 
between  0  and  6  degrees.  Roll  attitudes  oscillated  between  0  and  1.6 
degrees.  The  angle  of  attack  held  at  a  constant  4.6  degrees.  The 
normal  acceleration  was  in  the  noise  level  about  zero.  True  airspeed 
maintained  a  constant  660  ft. /sec. 

Test  #2  (Demo  A2.2)  was  conducted  as  a  static  test,  running 
closed-loop  with  the  FCL  on.  The  results  showed  the  pitch  rate  oscil¬ 
lates  between  +0.4  radian/second  (which  is  approximately  2 
degrees/second)  and  -0.04  radian/second.  Meanwhile,  the  roll  and  yaw 
rates  were  in  the  noise  level  about  zero.  Pitch  attitude  oscillated 
between  0  and  7.4  degrees,  while  roll  attitude  varies  between  0  and 
7.4  degrees.  The  angle  of  attack  maintained  a  constant  4-degree 
value.  The  normal  acceleration  was  in  the  noise  level  around  zero, 
and  the  true  airspeed  varied  between  680  and  760  ft. /sec. 

Test  #3  (Demo  A2.3)  was  conducted  as  a  dynamic  test  to  see  if  the 
FCL/EOM  closed-loop  system  would  indeed  stabilize  itself  after  being 
perturbed.  The  source  of  the  perturbation  for  this  demonstration  was 
in  the  form  of  a  4-volt,  0.5-second  input  to  the  pitch  stick  channel. 
Since  the  applied  stick  force  should  only  perturb  the  pitch  axis,  it 
would  be  expected  that  no  noticable  changes  would  occur  in  the  roll 
and  yaw  axes  parameters.  This  holds  true  for  the  results  of  our  test 
as  roll  rate,  yaw  rate,  and  roll  attitude  do  not  vary  at  all  from 
their  timmed  conditions.  Also  as  expected,  all  of  the  pitch  axis  var¬ 
iables  are  affected,  taking  the  form  of  a  damped  sine  wave.  Pitch 
rate  reached  a  maximum  value  of  about  0.455  radian/second  (26 
degrees/second)  in  the  0.5  second  that  the  +12  pounds  of  applied  pitch 
stick  force  before  the  dampening  process  begins.  Pitch  attitude 
climbed  to  a  value  of  around  12.3  degrees,  while  the  angle  of  attack 
went  as  high  as  approximately  7.5  degrees  before  dampening  out  to  its 
trim  value  of  4  degrees.  Normal  acceleration  rose  as  high  as  around 
248  ft./sec2.  All  of  the  pitch  axis  parameters  damped  out  to  their 
timmed  state  after  approximately  5  seconds. 

In  conclusion,  all  of  the  test  objectives  for  Demo  A2  were 
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achieved. 


2. 1.5. 2. 3  Verification  of  the  Single  Channel  Flight 

Control  Software 

The  tests  required  for  verification  and  functional  testing  of  the 
austere  single  axis  flight  control  software  were  organized  in  a  manner 
designed  to  verify  the  computer  program,  starting  with  the  basic 
modules  and  progressing  to  a  totally  integrated  functional  test.  The 
following  test  sequence  was  used: 

•  Executive 

•  I/O  Scaling 

o  Initialization 

•  Mode  Control 

•  Control  Law  Module  Test 

•  Control  Law  Functional  Tests 

•  Redundancy  Management  Tests. 

The  Executive  tests  verified  timing  and  progam  structure.  The  I/O 
scaling  verified  correct  data  tansfers  between  the  AN/AYK-15  and  the 
simulation  processor.  Initialization  testing  verified  that  the 
appropriate  variables  were  properly  initialized.  The  mode  and  switch 
logic  tests  were  performed  to  verify  the  control  panel  operation  and 
switching  operations  that  are  used  by  the  control  law  modules.  The 
control  law  modules  were  first  tested  individually  to  verify  proper 
operation  and  collectively  to  verify  functional  performance.  Finally, 
redundancy  management  operation  was  tested  to  verify  fault  detection 
and  signal  selection  operation. 

2. 1.5. 2. 4  FCL  Iteration  Rate  Study 

The  basic  purpose  of  the  FCL  iteration  rate  study  was  to  deter¬ 
mine  the  impact  of  reduced  FCL  iteration  rates  upon  the  performance  of 
the  A-7D  "Austere  Single  Channel  Flight  Control  System."  The  study  was 
to  show  whether  or  not  the  integrity  of  the  simulation  would  be 
affected  when  lower  iteration  rates  were  implemented.  Use  of  lower 
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iteration  rates  would  result  in  more  spare  simulation  time, 
specifically,  this  FCL  iteration  rate  study  would  be  used  to: 

•  Compute  the  execution  time  of  each  executive  task 
(and,  in  turn,  the  spare  time)  for  each  of  the  eight 
minor  frames. 

•  Provide  data  for  a  general  analysis  to  be  performed 
by  recording  the  outputs  of  simulations  run  under 
identical  flight  conditions  (cruise  mode)  but  at 
varying  iteration  rates.  These  outputs  will  then  be 
compared  to  the  outputs  of  the  baseline  validation 
software  run  at  80-Hertz  rate. 

After  the  test  was  completed,  a  listing  of  all  of  the  new  FCL  pro¬ 
cedures  were  provided.  The  FCL  timing  variables  affected  by  these 
procedures  were  highlighted  on  listings  and  given  a  unique  identifying 
label.  This  unique  label  was  included  as  an  element  in  a  matrix  which 
was  constructed  according  to  Figure  2-8.  In  the  left  hand  column,  the 
procedures  which  were  changed  are  listed.  Broken  out  under  each  pro¬ 
cedure  are  the  variables  of  the  procedure  which  now  possess  different 
values  due  to  the  modif i ctions .  Across  the  top  of  the  matrix  are  the 
various  iteration  rates  that  were  used  during  the  study.  File  compar¬ 
isons  of  all  modifications  to  existing  procedures  were  provided.  The 
reasons  for  these  modifications  were  explained  in  the  Iteration  Rate 
Study  Post-Test  Requirements  Technical  Memo. 

2.  ].5. 2. 5  Verification  of  the  Quad  Channel  Flight  Control  Software 

The  tests  required  for  verification  and  functional  testing  of  the 
quad  channel  flight  control  software  were  the  same  tests  used  in  the 
single  channel  flight  control  software  verification  discussed  in  Sec¬ 
tion  2. 1.5. 2. 3,  but  using  only  pitch  attitude  as  the  input. 


2. 1.5. 3  DSF  Status  and  Utilization  Status 


STATUS 

Direct  Coupled  Flight  Control  System  Validation  (SD80/PDP-11/40 ) 

(I)  OCT  76. 

Digital  Hardware  Voter/Monitor  Design  and  Development  (I)  FEB  77 
Digital  Hardware  Voter/Monitor/Hydraulic  Actuator  Integration  and 
Evaluation  (C)  FEB  77 

4-Port  Memory  Design  and  Development  (I)  JUL  77 
Develop  Cockpit  System  (C)  OCT  76 

Digital  Aero  Model  Development  and  Test  (PDP-11/34)  (C-I)  FEB  79 

Design  and  Develop  Flight  Control  Specification  with  JOVIAL 
Language  (I)  FEB  80 

Single  Remote  Terminal/Flight  Control/EOM  (JOVIAL,  1553A  Mux  Bus) 
Integration  and  Validation  (I)  FEB  81 

Simplex  Flight  Control  System  Integration  (1553A  Mux  Bus,  JOVIAL) 
(I)  MAY  82 

Quad  Redundant  Flight  Control  System  Integration  (I)  NOV  82 

UTILIZATION 

Technology  Interchanges  with  Digital  Synthesis 

CL-:,  Appliction  of  MIL-STD-1589B  and  MIL-STD-1750  to  Flight  Control 
Lockheed  (GA) ,  Discussions  on  Using  and  Applying  JOVIAL  to 
Flight  Control 

Boeing,  McDonnel  Douglas,  Discussions  on  Use  of  MIL-STDs  prior  to 

Release  of  RFP  for  C-X 

SEAFAC ,  Continuous  Discussions 

FIGL,  Digital  Architecture 

FIMS,  Mission  Adaptive  WING  ADP 

FIF,  Forward  Swept  WING  ADP 

FI I ,  AFTI/F-16 

RADC/AFATL,  Input  to  Ada  Program  Support  Program 
Industry  Assessment 


2. 1.5. 4  DSF  Support  Requirements 


The  Digital  Synthesis  Facility  required  the  following  support 
throughout  the  ICSES  contract: 

o  Development  of  test  plans  and  procedures 
o  Modification  of  the  FCL  executive  for  iteration  rate 
and  the  delta  times  of  the  computational  procedures 
o  Execution  of  the  test  procedures 
o  Generation  of  technical  memos 

o  Analytical  support  including  selection  of  representative 
samples  and  calculation  of  execution  times,  categorization 
of  the  FCL  and  identification  of  the  advantageous/detrimental 
constructs  of  JOVIAL  J73/I 

o  Modification  of  the  EOM  software  including  the  modifications 
to  provide  the  capability  to  mask  and  rescale  the  interface 
data  between  12-bits  and  less  for  each  input  signal 
individually 
o  URT  hardware  support 

o  Completion  of  the  design  in  the  new  FCL  executive  impacted 
by  DAIS  protocol 

o  Implementation  of  the  new  executive 
o  Recoding  of  routines 
o  Implementation  of  routines 
o  Literature  search. 


The  Digital  Synthesis  Flight  Engineering  Facility  has  provided  a 
means  to  obtain  hands  on  experience  in  application  and  use  of  control 
systems  and  applicable  military  standards  including  1553  aircraft  mul¬ 
tiplex  bus  data  standard,  the  1750  minicomputer  instruction  set 
architecture  standard,  and  the  1589  JOVIAL  higher  order  language  stan¬ 
dard.  The  DSFEF  provides  a  means  to  evaluate  control  system  design 


guides  and  measures  assessment  methods  for  control  system  perfc 
(i.e.,  ride  quality,  PIO  tendencies,  response  crispness,  etc.) 
MUX  integrated  control  system. 

The  DSFEF  software  support  task  has  provided  a  data/expr 
base  on  "effectiveness/efficiencies"  of  standardized  systems  for 

-  Computer  efficiency/availability  for  a  wide  variety 
of  computers 

-  Applicability  to  multi-variable  controls 

-  Determination  of  critical  design  rules 

-  Programmer  efficiency 

-  Validation  and  verification  comparisons 

Note  that  the  experience  and  knowledge  gained  in  use  of  the 
implies  a  strong  need  for  facility  capabilities  to  emulate 
designs  in  advance  of  freezing  a  design  during  the  development 
cess.  Early  emulation  of  system  designs  will  provide  a  me 
anticipate/avoid  design  flaws  or  "bad"  designs.  Also,  expe 
gained  in  documentation  and  configuration  control  for  changing  z 
needed  for  DIGISYN  may  provide  an  experience  base  for  AF  life 
management  control  . 

Recommendations 

The  use  of  the  DSFEF  has  demonstrated  the  importance  to  1 
means  to  evaluate  PCS  capability.  This  capability  should  be  cor 
and  upgraded  to  a  configuration  with  specific  standards  orient 
This  would:  give  the  AF  a  means  to  provide  a  credible  influe 

evaluation  ol  standards;  provide  a  means  for  performing  early  £ 
ic  design  hot  bench  testing;  enable  exploration  of  architectui 
information  path  options;  provide  provide  a  means  to  see  the 
oi  control  standards  on  fault  tolerance,  flying  qualities,  ft 
automations,  etc:.,  with  pi  1  ot- 1  n- the- loop  omul  at  lon/simul  at  ions . 

A  second  generation  DJGISYN  should  be  procurred  and  implen 
Specific  requirenients/cricical  capacities  which  should  be  addres 


such  a  procurement  include: 

-  Pilot-in-the-loop 

-  Safety 

-  Fault  tolerance 

-  Freedom  from  idiosyncrasies 

-  Non-linear/coupled  EOM 

-  Configuration  control 

A  second-generation  DIGISYN  should  also  have  the  capability  to  address 
critical  flight  control  technologies,  as  listed  in  Table  2.1-2. 
Consideration  should  be  given  to  comparative  efficiencies  obtained 
through  emulation  of  the  target  computer  and  also  the  use  of/tie  in 
with  FIGD  EOM  support.  Also,  a  formal  configuration  control  approach 
for  this  type  of  facility  must  be  addressed.  However,  specific  confi¬ 
guration  control  requirements  can  be  adopted  so  as  not  to  impede 
development  efficiency  (see  Section  2.4). 


Table  2  J- -.2  Flight  Control  Technology  Issues 


Specification  of  system  level  requirements 

-  display/avionics/f ire  control  integration 

-  manual  vs.  automatic  modes 
FCS  test  and  evaluation 

-  multiplicity  of  modes 

-  S/W  processes  which  are  transparent  to  T&E 

-  redundancy  management  effectiveness 
DFCS  design 

-  avionics  integration 

-  handling  qualities  specs,  for  non-classical  modes 

-  servo  loop  stability 

-  system  simulation 
Redundancy  management 

-  concepts  and  system  architecture 

-  sensor  interface 

-  distributed  processing 

-  testability 

-  reliability  assessment 
Control  law  design 

-  design  criteria 

-  flight  safety 

-  handling  qualities 

-  re-design  based  on  flight  test 
Handling  qualities 

-  criteria 

-  flight  test  techniques 

-  control/display  interface 

-  task-tailored  handling  qualities 


2.2  AFTI/F-16  PROGRAM 


2.2.1  Program  Background  and  Goals 

In  1977  a  study  was  conducted  to  determine  the  potential  payoff 
to  be  derived  by  the  application  of  the  five  technologies  shown  below 
to  an  F-16  : 

-  Direct  Force  and  Weapon  Line  Pointing 

-  Digital  Flight  Control  System 

-  Integrated  Flight  and  Fire  Control 

-  Aerodynamic  and  Structural  Design  Improvements 

-  Pilot/Vehicle  Interface  Advancements 

Before  the  trade  study  had  been  performed,  the  technologies  were 
assessed  relative  to  application  on  a  new  prototype  aircraft.  The 
trade  studies  were  partitioned  into  two  subsets. 

The  first  subset  was  a  configuration  study  in  which  aerodynamic 
and  structural  design  advancements  were  coupled  with  a  set  of  configu¬ 
ration  options  to  generate  varying  levels  of  advanced  flight  mode 
authority.  Incorporated  at  that  time  in  the  configurations  were  the 
aerodynamic  and  structural  design  improvements  available  from  the 
technology  base  in  the  form  of  an  improved  wing  and  attendant  fuselage 
changes  required  to  balance  the  airplane.  The  baseline  configuration, 
which  can  only  generate  decoupled  motion  in  the  pitch  axis,  was  used 
to  reference  the  performance  impacts  of  adding  yaw  decoupling.  A 
total  of  769  hours  of  wind  tunnel  tests  were  conducted  in  the  process 
of  aerodynamic  configuration  development.  A  point  design  was  evaluat¬ 
ed  for  each  configuration,  and  advanced  mode  authority  plus 
conventional  performance  were  computed.  A  definite  trend  was  esta¬ 
blished  with  respect  to  increasing  conventional  performance  penalty 
generated  as  advanced  mode  authority  was  increased. 

The  second  trade  study  subset  involved  determination  of  the 
payoff  derived  by  coupling  advanced  mode  control  authority  with 
integrated  flight  and  fire  control. 
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Small  amplitude  fuselage  pointing,  generated  either  with  a  train- 
able  f u‘  lage  or  a  trainable  gun,  rapidly  saturated  the  gunnery 
objectives  at  an  authority  much  smaller  than  could  be  gained  with  the 
minimum  conventional  performance  impact  conf iguration .  Also,  very 
large  advantages  were  identified  for  cases  in  which  flight  control  and 
tire  control  were  integrated. 

The  benefit/penalty  assessment  coupled  with  a  reduction  in  pro¬ 
gram  funding  resulted  in  the  elimination  of  the  aerodynamic  and 
structural  design  improvement  technology  from  the  planned  program.  On 
22  December  1978,  General  Dynamics  was  selected  to  develop  the  AFTI 
Technology  Set  I  and  the  AFTI/F-16  Testbed  Aircraft. 

Program  rationale  was  clearly  stated  in  the  contract  work  state¬ 
ment.  Highlights  of  the  rationale  include: 

1.  Provision  of  a  demonstrator  aircraft  for  demonstration 
and  validation  of  the  integrated  technologies  in  a 
configuration  that  permits  functional  assessment  in  the 
tactical  environment. 

2.  Development  and  integration  of  the  individual  technologies 
in  a  manner  which  minimizes  the  need  for  testbed  aircraft. 

3.  Provision  of  a  consistent  and  compatible  goal  that 
encourages  integration  across  the  large  number  of 
functional  disciplines  involved. 

4.  Kstabl i shment  of  design  criteria  as  the  salient 
objective  of  the  individual  projects  in  addition 
to  the  total  r  ngram. 

The  testbed  aircraft,  called  a  technology  demonstrator,  (Figure 
2.2-1)  is  in  fact  a  system  prototype.  The  emphasis  in  technology  is 
consistent  with  emerging  fast-track  technology,  microelectronic-based 
systems,  and  Air  Force  needs,  which  are  improved  navigation,  engage¬ 
ment  and  weapon  delivery  capability  -  or  weapon  line  control. 

2.2.2  Program  Description 


The  AFTI/F-16  Advanced  Development  Program  is  a  joint  USAF,  Navy, 
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Figure  2.2-1  AFTI/F-16  Technology  Demonstrator 
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and  NASA  effort  aimed  at  the  development,  integration,  and  flight  test 
evaluation  of  emerging  technologies  for  improving  fighter  aircraft 
mission  effectiveness.  Major  development  thrusts  include  Digital 
Flight  Control  System,  Direct  Force  and  Weapon  Line  Control,  Pilot 
Vehicle  Interface  and  Automatic  Maneuvering  Attack  System  (AMAS) . 
Development  of  an  advanced  highly  reliable  digital  flight  control  sys¬ 
tem  ( DFCS)  is  the  core  technology  building  block  for  accomplishing  the 
overall  AFTI/F-16  objectives. 

Application  of  digital  flight  control  technology  offers  the 
opportunity  to  integrate  these  advanced  concepts  in  a  multi-role, 
high-per f ormance  fighter  aircraft  to  achieve  operational  versatility, 
improved  overall  mission  effectiveness  and  decreased  cost  of  ownership 
without  sacrificing  system  reliability  and  safety.  The  DFCS  portion 
of  the  program  encompasses  the  complete  development  and  integration  of 
a  multimode  triplex  digital  FBW  flight  control  system  employing  decou¬ 
pled  six  DOF  flight  path  control  capabilities.  Major  technical 
thrusts  include  the  development  of:  (a)  task-tailored  mutimode  con¬ 
trol  laws  incorporating  direct  force  and  weapon  line  pointing 
features,  (b)  triply  redundant  flight  control  computer  complex  using 
the  BDX-930  processor,  (c)  advanced  redundancy  management  techniques, 
winch  provide  essentially  two  fail-operate  capability  and  meets  or 
exceed;:  a  loss  of  control  reliability  of  1  x  10-7  failures/flight 
hour,  id)  integrated  crew  station  using  multipurpose  controls  and  dis¬ 
plays,  and  (e)  compatible  interface  for  integration  with  other 
subsystems,  such  as  fire  control,  mission  avionics  and  associated  mul¬ 
tipurpose  displays,  through  a  common  digital  data  bus. 

Organizing  primary  flight  control  modes  and  associated  control 
laws  based  on  specific  mission/weapon  delivery  requirements  offers  the 
opportunity  for  enhancing  overall  mission  effectiveness,  while  at  the 
same  time  emphasizing  the  pilot's  role  as  a  mission  manager  rather 
than  a  subsystem  operator.  In  consonance  with  this  design  philosphy, 
the  following  basic  mission  tailored  control  modes  are  implemented  in 
the  AFTI/F-16  testbed;  (a)  Normal  Mode  with  ancillary  functions  for 
take-of f/landing ,  refueling,  formation,  cruise  and  pilot  relief;  (b) 
Air-to-Air  Gunnery  Mode,  fc)  Air-to-Gr ound  Mode,  and  (d)  Air-to-Ground 
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Figure  2.2-2  Triplex.  Digital  Flight  Control  System 


Bombing  Mode.  Control  law/sensor  reconfiguration  schemes  are  also 
employed  to  provide  optimum  flight  characteristics  based  on  available 
functioning  system  elements.  In  each  of  these  primary  modes,  the 
flight  control  system  provides  the  necessary  flight  path  decoupling, 
and  desired  vehicle  response  characteristics,  specifically  tailored 
and  optimized  for  the  appropriate  mission  segment.  Digital  technology 
is  espeeialy  suited  for  implementing  these  sophisticated  inner  loop 
control  functions  and  interfacing  with  other  avionic  subsystems  such 
as  the  tire  control  system. 

During  Phase  I  of  the  program,  the  digital  flight  control  system 
(DFCS)  was  designed,  constructed,  and  successfully  flight  tested.  In 
addition  to  the  flight  control  system,  other  emerging  technologies 
have  been  investigated  during  this  phase.  Among  these  are:  a  wide 
f ield-of-view  HUD,  multi-purpose  display  unit,  and  a  voice  interaction 
system.  The  significance  of  the  AFTI  program  relative  to  future 
fighter  aircraft,  however,  lies  in  the  accomplishments  anticipated  for 
Phase  II.  In  this  Phase  of  the  program,  denoted  by  the  acronym  AMAS 
(tor  automated  maneuvering  attack  system-Figure  2.2-3),  the  digital 
flight  control  system  will  be  integrated  with  other  avionics  subsys¬ 
tems  -  the  stores  management  system,  and  the  fire  control  system. 
Through  this  judicious  coupling  of  flight  systems,  the  advantages  of 
t ask-tai lored  control  laws  and  decoupled  motion  made  possible  by  the 
DFCS  and  advanced  aerodynamic  structure  are  brought  directly  to  bear 
on  the  problem  of  weapon  delivery.  When  the  pilot  and  his  crew  sta¬ 
tion  are  also  properly  integrated,  the  result  will  be  significantly 
enhanced  fighter  mission  effectiveness. 

Among  the  new  technologies  to  be  evaluated  during  the  AMAS  phase 

are: 

-  YAG  Laser /FL I R 

-  Helment-mounted  sight 

-  Rol I -stabi 1 i zed  radar  altimeter 

-  Digital  map  and  display 

-  Standardized  avionics  integrated  fuzing  (SAIF) 
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Figure  2.2-3  Automated  Maneuvering  Attack  System 


2.2.3  Program  Status  and  Plans 


The  AFT I /F— 16  demonstration  aircraft  is  currently  under  modifica¬ 
tion  at  General  Dynamics'  Ft.  Worth  facility  in  preparation  for  the 
AMAS  phase  of  the  program. 

The  concept  for  the  AMAS  ^hase  is  to  add  an  electro-optical 
tracker  to  the  testbed  aircraft  and  to  host  the  integrated  flight/fire 
control  FFC)  system  software  in  the  testbed  aircraft.  The  principal 
objectives  of  this  phase  are: 

-  Integration  of  digital  multimode  f light-control  system, 
advanced  fire-control  system,  advanced  controls  and 
displays,  and  weapons  for  validation  of  IFFC  system 
performance  and  missis^  effectiveness. 

-  Identification,  design,  and  implementation  of  IFFC 
configurations  and  quantification  of  improvements  in 
weapon  delivery  capability,  accuracy,  and  survivability. 

-  Determination  of  pilot  acceptance,  adaptability,  and 
workload  reduction  associated  with  the  IFFC  modes  in 
the  weapon  delivery  phase. 

Several  design  features  have  been  specifically  developed  for 
demonstration  of  the  low-altitude  attack  capability: 

-  System  Wide  Integrity  Management  (SWIM) 

-  Automatic  Ground  Avoidance 

-  Automatic  Ingress  and  Fgress  Steering 

-  how  Altitude  Radar  Auto  Pilot 

-  Conformal  Sensor/Tracker  Installation 

The  AMAS  system  has  been  updated  with  available  F-16  Multinational 
Staged- Improvement  Program  (MSIP)  hardware.  The  benefits  of  this 
change  are  to  provide  alJ  AMAS  avionic  software  in  standard  J73  source 
code  and  to  improve  testbed  aircraft  suppor tabil ity . 

At  the  present  time,  the  AFTI/F-16  program  is  expected  to  be  com¬ 
pleted  by  mid-1985.  There  is,  therefore,  no  formal  definition  for 
Phase  III  activities.  However  it  is  reasonable,  and  quite  possible, 
to  expect  the  basic  AMAS  system  demonstrated  during  Phase  II  to  be 
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expanded  to  include  terrain  -following/terrain  -avoidance  and  night- 
attack  capability. 

2.2.4  Work  Accompl i shed 

2. 2. 4.1  Documentation  and  Design  Review  Support 

Over  the  course  of  the  program  SCT  reviewed  and  evaluated 
software  documentation  produced  by  General  Dynamics.  This  documenta¬ 
tion  included: 

-  Computer  Program  Development  and  Product 
Specifications  for  the  Operational  Flight  Programs 
resident  in  the  flight  control  computers,  the  fire 
control  computers,  and  the  Stores  Management  Set. 

-  Computer  Program  Development  Plan 

-  Flight  Control  System  Software  Mechanization  Document 

-  System  Test  Plan 

-  Software  Verif ication/Validatin  Plans  and  Procedures 
for  stand-alone,  and  integrated  system  testing  of  the 
Operational  Flight  Programs. 

-  Software  Verification/Validation  Test  Reports 

-  Deficiency  Reports 

-  Software  Mechanization  Change  Requests 

-  Display  Control  Documentation 

-  Design  Review  Minutes 

All  documentation  was  evaluated  with  a  view  to  discovering  errors, 
inconsistencies,  omissions,  or  other  significant  departures  from 
accepted  industry  standards  and  known  system  operating  characteris¬ 
tics.  Detailed  comments  and  suggestions  were  provided  to  the  Program 
Office  and  all  review  activities  were  documented  in  the  weekly  activi¬ 
ty  reports  as  well  as  the  monthly  progress  and  status  reports. 

SCT  also  provided  continuous  design  review  support  throughout  the 
program.  This  support  included  participation  in  all  system  design 
reviews,  safety  reviews,  and  numerous  technical  coordination  meetings, 


including  the  Flight  Readiness  Review,  which  were  conducted  at  General 
Dynamics/Ft.  Worth  as  well  as  at  the  Program  Office  at 
Wright. -Pat  ter  son  AFB  ,  Ohio. 

2. 2. 4. 2  Software  Design  Review  and  Analysis 

The  purpose  of  SCT's  software  design  review  and  analysis  task  was 
to  provide  a  comprehensive  independent  assessment  of  the  software 
design.  The  software  design  was  reviewed  for  adequacy  and  complete¬ 
ness,  as  well  as  compatabil ity  and  compliance  with  requirements 
specifications.  Two  methods  were  employed  to  validate  the  basic 
integrity  of  the  OFP  software.  First,  a  detailed  knowledge  of  the 
software  was  obtained  through  a  continuous  process  of  documentation 
review,  participation  in  technical  coordination  meetings,  pencil  and 
paper  analysis  of  logic  flow  and  control  laws,  and  first-hand  observa¬ 
tion  during  the  V&V  testing  effort.  Second,  both  an  emulation  and  a 
batch  simulation  were  constructed  to  examine  specific  problems  and 
system  characteristics.  The  batch  simulation  will  be  discussed  in 
Section  2. 2. 4. 4  -  On  Site  Support. 

overall  evaluation  and  specific  recommendations  concerning  the 
uoi l  ware  design  were  provided  in  the  form  of  documentation  reviews, 
commentaries  on  the  minutes  of  system  design  reviews,  and  basic  "posi¬ 
tion"  papers  formulated  and  issued  as  required  throughout  the  program. 
In  particular,  SCT  provided  analyses  and  recommendations  to  the  pro¬ 
gram  out  ice  on  the  following  issues: 

-  DFCS  control  law  logic  design 

-  DFCS  control  lav/  intermediate  data  analysis 

-  Handling  of  dual  failures  by  the  Failure  Management 
System 

-  Random  flight  control  computer  trip-outs 

-  Flight  control  computer  burn-in  requirements 

-  Low  level  V&V  testing  of  fully  integrated  OFPs 

-  Sequential  data  link  receiver  failures 

-  Software  testing  issues 

-  Output  s e lector /monitor  robustness 

-  control  law  rucon) lguretion 
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Prior  to  First  Flight,  SCT  organized  an  extensive  test  coverage  audit 
of  the  flight  control  software.  The  purpose  of  this  software  audit 
was  to  verify  that  the  computer  program  test  coverage  is  adequate  to 
safety  of  flight  for  the  flight  test  program.  The  verification  activ¬ 
ity  consisted  of  reviewing  software  test  procedures  and  correlating 
4  them  with  the  requirements  set  forth  in  the  DFLS  mechanization  docu- 

*  ment  to  assure  that  completed  and  planned  tests  support  safety  of 

flight.  The  scope  of  tne  audit  covered  the  computer  programs  resident 
in  the  AFTI  Flight  Control  Computers  (FLCC).  The  critical  software 
segments  were  the  flight  control  laws  and  the  failure  management 

« 

implementation.  Remaining  segments  were  reviewed  on  a  sample  basis. 
The  auditors  assured  that  a  professional  and  prudent  verification 
activity  was  accomplished  by  General  Dynamics.  Subsequent  to  the  V&V 
testing  activity  a  software  test  results  audit  was  performed  to  verify 
that  actual  test  results  were  in  agreement  with  expected  test  results. 

As  noted  above,  in  addition  to  a  comprehensive  software  review 
and  various  "pencil  and  paper"  analyses  SCT  also  constructed  an  emula¬ 
tor  to  examine  specific  flight  control  system  char act er i ct i cs .  The 
AFTI /F -16  Emulator,  written  in  Pascal  and  hosted  on  a  Vax  11/780  at 
SCT '  :>  Palo  Alto  facility ,  became  fully  operational  early  in  1981.  It 
contains  the  software  written  by  General  Dynamics,  models  of  various 
sensors,  the  ISA  interface  and  a  longitudinal  axis  model  of  the  P-16. 
It;  is  driven  by  a  discrete  event  simulation  executive  which  simulates 
three  FLCC ' s  running  asynchronously.  The  software  residing  in  the 
FLCC  is  a  high  order  representation  of  the  General  Dynamics  software, 
ft  accurately  reflects  the  General  Dynamics  design  in  the  areas  of  ISA 
and  input  selector  monitors.  Failure  Management,  IOC  processing  and 
hardware  (particularly  ISA  hardware).  The  controls  law  have  been  sim¬ 
plified  and  only  Longitudinal  normal  and  decoupled  modes  are 
Implemented.  The  emulator  war  utilized  to  explore  a  varitey  of  flight 
control  system  characteristics  and  problems;  those  are  summarized 
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-  Redundancy  Management  Analysis 

-  selector/monitor  design 

-  reset  logic 

-  watch-dog  timer  disable  logic 

-  high  level  device  failures 

-  mode  transition 

-  failure  modes  and  effects 

-  persistence 

-  trip  levels 

-  interchannel  tracking 
Control  Law  Studies 

-  frequency  response,  nominal  and  failure 

-  mode  transition/reconfiguration 

-  control  law  intermediate  data  analysis 

-  step  response 

FCS  Software  Integration 

-  test  matrix  correlation 

-  software  change  request  validation 
System  V/V  Testing 

-  refine  test  procedures 

-  DR/MCR/SCR  validation 

-  test  results  correlation 
IFFC 

-  architecture  studies 
General 

-  resolution  of  discrepancies  between  the 
mechanization  document  and  the  product 
specification. 

2. 2. 4. 3  Lateral  Investigations 

In  addition  to  providing  an  independent  assessment  of  the 
software  design,  SCT  was  also  tasked  to  provide  analysis  in  support  of 
design  trade-off  studies,  and  to  permit  the  program  office  to  properly 
evaluate  potential  changes  to  the  program.  The  most  significant  of 
these  activities  were  the  IBU  modeling  effort  and  the  preliminary  per- 
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formance  assessment  study. 

IBU  modeling  effort  -  The  independent  back-up  unit  is  a  simple, 
but  vitally  important,  analog  controller  designed  to  ensure  safe 
flight  in  the  event  of  digital  system  failure.  Performance  require¬ 
ments  of  the  IBU  are  to  meet  Level  3  requirements  of  MIL-F-8785  (ASG) 
for  cruise  and  descent  and  Level  2  for  landing.  Control  in  the  longi¬ 
tudinal  axis  is  provided  by  a  pitch-rate  command  system.  The  pitch 
command  from  the  stick  is  shaped  and  then  lagged  by  a  prefilter.  The 
pitch  rate  error  signal  is  then  gained  and  fed  through  a 
proportional-plus-integral  network.  Different  lead/lag  compensators 
for  the  gear-up  and  gear-down  configurations  augment  stability  margins 
and  improve  handling  qualities  over  the  entire  flight  envelope.  SCT 
constructed  a  computer  simulation  of  the  IBU  by  transforming  the  con¬ 
tinuous-time  transfer  functions  into  difference  equations.  This 
simulation  was  then  used  to  provide  confirmation  of  the  IBU's  stabili¬ 
ty  and  frequency  response  characteristics. 

Performance  Assessment  -  The  AFTI/F-16  is  a  technology 
demonstration  for  future  fighter  aircraft.  As  such  it's  primary  role 
is  that  of  being  a  testbed  to  explore  new  technologies  for  their 
potential  in  enhancing  fighter  aircraft  performance  and  mission  effec¬ 
tiveness.  It  is  reasonable  to  expect  that  the  new  technologies 
incorporated  into  the  AFTI/F-16,  when  taken  together,  will  result  in 
significant  improvements  in  target  acquisition  time,  tracking  accura¬ 
cy,  probability  of  hit,  and  survivability.  However,  there  needs  to  be 
precise  quantification  of  this  improvement  as  well  as  the  correlation 
between  specific  technology  and  enhanced  performance.  SCT  prepared  a 
detailed  plan  delineating  methods  for  conducting  comprehensive  and 
meaningful  performance  assessment  studies. 

2. 2. 4. 4  On-Site  Support 

SCT  provided  on-site  support  to  the  AFTI/F-16  Joint  Test  Force 
(JTF)  at  Edwards  AFB.  These  services  were  provided  starting  with  the 
digital  flight  control  system  (DFCS)  development  phase  at  General 
Dynamics  Fort  Worth  and  continuing  through  actual  flight  test.  SCT 


supported  this  program  in  5  distinct  areas: 

•  Development  of  six-degree-of-f reedom  batch  simulation 
of  the  AFTI/F-16. 

•  Systems  engineering  support  to  the  analysis,  development 
effort,  and  flight  test  of  the  DFCS  phase. 

•  Support  of  flying  qualities  test  and  evaluation  of  DFCS. 

•  Systems  engineering  support  of  development  efforts 
required  for  the  AMAS  phase. 

•  Documentation  control  and  clerical  support  to  the  JTF. 

On-site  support  at  Edwards  AFB  was  accomplished  under  technical  direc¬ 
tion  of  NASA  DFRF ,  as  part  of  an  MOM  between  NASA  DFRF  and  AFWAL. 
Operational  management  of  this  support  was  accomplished  in  matrix 
fashion:  SCT-to-DFRF-to-JTF. 

On-site  support  services,  under  the  ICSES  contract,  ended  on  30 
September  1983. 

Batch  sjmigatiQn 

A  full  6-DOF  batch  simulation  of  the  AFTI/F-16  was  developed  at 
the  request  of  NASA  DFRF.  The  simulation  was  validated  over  a  limited 
range  of  flight  conditions  for  the  IBU  control  laws,  only.  This 
effort  proved  to  be  much  more  difficult  and  costly  than  originally 
conceived.  This  was  due  mainly  to  the  enormous  size  and  complexity  of 
the  aerodynamic  data  base  and  the  attendant  problems  of  validating  the 
aero  data  package  after  its  installation  on  the  Cyber  computer  facili¬ 
ty  at  NASA  DFRF. 

The  batch  simulation  effort  has  been  documented  in  an  informal 
report.  The  simulation  is  presently  hosted  on  the  NASA  DFRF  Cyber. 

QF.CS  Support 


During  the  DFCS  phase  of  AFTI/F-16,  SCT  supported  114  flights  at 
Edwards  AFB  over  a  12-month  period.  Prior  to  first  flight,  SCT  per¬ 
sonnel  were  instrumental  in  developing  the  technical  basis  and 


operational  ground  rules  required  for  support  of  the  tr iply-redundant , 
dual-fail  Op  DFCS.  This  included  participation  in  establishment  of 
the  software  review  and  control  process  -  which  was  instrumental  in 
the  conduct  of  an  orderly,  safe  flight  test  program.  The  support  pro¬ 
vided  to  DFCS  development  and  testing  was  in  four  principal  areas: 
software  systems,  flight  test  and  technical  reporting. 

Software  support  included  a  spectrum  of  activities  ranging  from 
development  of  top-level  understanding  of  DFCS  functions  to  dealing 
with  the  volume  of  paperwork  generated  by  the  software  control  pro¬ 
cess.  SCT  was  an  active  participant  in  establishing  the  Software 
Control  Board  (SCB) .  A  major  work  area  was  the  development  or  review 
of  confidence  tests  at  GDFW,  and  software  verification  and  validation 
testing.  SCT  also  generally  prepared  the  NASA  OFP  Release  Document 
for  each  DFCS  OFP  modification  after  the  airplane  entered  flight  tests 
at  Edwards  AFB .  There  were  a  total  of  13  OFPs. 

In  the  area  of  systems  support,  SCT  participated  in  various  sys- 
tems-related  tasks,  involving  both  hardware  and  software,  and  which 
usually  involved  cross-disciplinary  functions.  These  support  duties 
included  participation  in  the  Configuration  Control  Board  (CCB) , 
Flight  Readiness  Reviews  (FRR) ,  and  review  of  Discrepancy  Reports 
(DR) ,  Change  Requests  (CR)  or  Mechanization  Change  Requests  (MCR) .  A 
periodic  function  was  to  prepare,  and  often  give,  a  formal  NASA  Tech 
Brief  prior  to  each  flight  test  block,  first  flight  following  a  new 
OFP  installation,  or  after  a  major  system  anomaly  was  experienced  in 
flight  test.  Substantial  real-time  simulation  was  conducted  on  the 
AFFTC  simulation  of  AFTI/F-16  to  evaluate  various  features  of  DFCS 
software  redundancy  management  vs.  control  laws  vs.  system  dynamics. 
This  included  evaluations  of  trip  level  requirements  for  asynchronous 
DFCS  operation.  Control  law  modifications  were  routinely  evaluated 
prior  to  approval  of  MCRs  for  OFP  modification.  The  unique  test 
requirements  for  voice  command  received  considerable  support.  A  regu¬ 
lar  schedule  of  travel  to  GDFW  was  established  to  provide  support  of 
system  test  and  evaluation  on  the  GD  simulator. 

Once  testing  was  begun  at  Edwards  AFB,  the  direct  and  indirect 
support  of  flight  schedules  became  the  priority  work  item.  Flight 
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support  actually  started  well  before  the  airplane  was  delivered  to  the 
Joint  Test  Force  (JTF) .  Substantial  effort  was  required  to  define 
instrumentation  requirements,  control  room  layout,  go/no-go  parameter 
lists,  and  specific  operational  test  support  procedures.  A  control 
room  manual  was  prepared  by  SCT  for  DFCS  support.  Combined  systems 
tests  were  conducted  following  major  change  to  system  hardware  (in¬ 
cluding  the  airplane,  control  room,  and  instrumenataion) .  A  combined 
system  test  was  made  of  the  control  room  prior  to  the  airplane's  arri¬ 
val  at  Edwards  by  using  a  TM  tape  from  the  first  flight  at  GDFW. 
Routine  support  included  review  of  Block  Test  Plans,  participation  in 
crew  briefings,  flight  monitoring,  and  crew  debriefs.  Any  DFCS  anoma¬ 
ly  experienced  in  flight  became  the  subject  for  rigorous,  priority 
investigation  to  determine  probable  cause  and,  if  required,  present 
the  results  at  a  formal  NASA  Tech  Brief.  Substantial  support  was 
given  to  the  Hi-alpha  test  plan.  This  included  test  plan  review, 
simulations  at  GDFW  and  the  AFFTC,  and  support  of  NASA  Tech  Briefs. 

In  the  area  of  technical  reporting,  two  papers  were  jointly 
authored  by  SCT  with  NASA  on  the  DFCS: 

(1)  Mackall,  Ishmael  &  Regenie,  "Qualification  of  the 
Flight  Critical  AFTI/F-16  Digital  Flight  Control 
System",  A1AA-83-0060 ,  AlAA  21st  Aerospace  Science 
Meeting,  Jan.  10-13,  1983 

(2)  Ishmael,  Mackall  &  Regenie,  "Ramifications  of  the 
System  Design  of  the  AFTI/F-16  Digital  Flight  Control 
System",  5th  Digital  Avionics  Systems  Conference, 

Oct.  31  -  Nov.  3,  1983,  Seattle,  Wash. 

Flying  Qualities 

SCT  was  a  very  active  participant  in  flying  qualities  T&E  during 
DFCS.  This  support  was  of  two  types:  operational  support  of  the  JTF 
misison  requirements  and  general  technology  support. 

Operational  support  covered  a  variety  of  activities  including: 

•  direct  flight  test  support  (crew  briefings  and 

debriefings,  and  control  room  monitoring  of  flights), 
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•  test  planning  (supplementing  the  Test  Plan  Document 
with  specific,  day-to-day  details  which  enhanced 
the  quality  of  testing  results  or  test  technique) , 

•  active  participation  in  the  configuration  control 
process, 

•  review  of  propsed  DFCS  control  law  changes, 

•  flying  quality  discrepancy  investigations. 

One  of  the  objectives  of  the  AFTI/F-16  program  is  to  contribute 
to  an  expanded  technology  data  base.  SCT  was  instumental  in  fulfil¬ 
ling  this  responsibility  during  the  DFCS  flight  test  phase.  This  was 
done  by  searching  for,  or  creating,  test  opportunites  throughout 
flight  test.  These,  when  fully  exploited  and  reported,  contributed  to 
flight  control  technology  with  aircraft  systems  and  missions  such  as 
those  encompassed  by  the  AFTI  program.  Usually,  but  not  always,  these 
technology  opportunities  resulted  from  a  flying  qualities  discrepancy. 
Thus,  the  SCT  support  to  flight  operations  and  technology  were 
integrated  processes. 

There  were  10  principal  areas  where  SCT  provided  flying  qualities 
expertise  to  the  DFCS  flight  test  program,  as  follows: 

1.  Roll  pilot-induced-oscillation  (PIO):  Three  PIO 
experiences  were  encountered,  all  in  the  roll  axis. 

The  first  occurred  in  the  standard  normal  control 
mode  during  power  approach.  The  task  was  an  offset 
approach,  touch  &  go,  in  a  gusting  crosswind.  The 
second  was  at  1.2M  in  IBU.  The  third  was  in  the 
simulated  USN  carrier  approaches.  These  PIO  events 
were  analyzed  by  SCT. 

2.  U.S.  Navy  carrier  approach  "simulations":  These  were 
actual  power  approaches,  using  a  Fresnel  Lens  Optical 
Landing  System  (FLOLS) ,  and  a  ship' s-qualif ied  Landing 
Signal  Officer  (LSO) .  All  aproaches  were  terminated 
with  standard  Shipboard  wave-off  techniques,  commanded 
by  the  LSO.  An  F-16A  was  tested  first  to  develop  the 
test  technique  and  to  provide  an  AFTI  baseline.  Roll 
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PIO  was  encountered  with  AFTI;  it  was  identical  with 
that  obtained  in  the  cross-wind  landing.  SCT  personnel, 
experienced  in  carrier  air  operations,  supported  both 
these  tests  by  assisting  the  LSO,  preparing  custom  pilot 
evaluation  scales,  and  arranging  Askania  coverage  for 
the  AFTI  test. 

3.  Pilot  evaluation  scales:  the  AFFTC  flight  test  team 
was  experienced  with  the  standard  methods  for  obtaining 
pilot  ratings  and  comment  data.  However,  in  view  of 

the  practical  limitations  of  the  AFTI/F-16  test  coverage, 
there  was  genuine  concern  that  these  would  be  inadequate. 
To  supplement  the  evaluation  process,  SCT  devised 
AFTl-unique  evaluation  forms.  These  were  used  routinely 
for  most  flights  of  flying  qualities  interest. 

4.  Roll  ratcheting:  This  problem,  previously  encountered 
with  the  AFTI/F-16  aircraft  was  encountered  very  early, 
and  an  attempt  was  made  to  cure  the  problem  with  roll 
command  prefilters.  SCT  performed  substantial  analyses 
of  system  dynamics  (airframe-control  laws-pilot); 

these  successfully  explained  the  cause  of  the  ratcheting 
and  suggested  a  cure.  A  major  conclusion  was  that,  for 
AFTI,  command  prefilters  were  an  unlikely  source  for  a 
ratchet  cure  -  -  although  ratcheting  could  be  eliminated 
at  the  expense  of  degraded  tracking.  This  was  verified 
by  case  history  data  from  3  successive  DFCS  OFPs. 

5.  Handling  qualities  during  tracking  (HQDT) :  SCT  proposed 
the  use  of  HQDT  for  testing  AFTI  flying  qualities  in  the 
PA  configuration.  This  was  actually  done,  using  an 
F-16  as  the  target  aircraft  (to  match  AFTI's  approach 
speed).  Although  the  requirement  to  avoid  jetwash  was 

a  real  problem  (it  required  extreme  depression  of  the 
fixed  reticle  sight),  the  method  successfully 
demonstrated  all  the  features  of  AFTI  PA  flying  qualities 
that  were  found  with  more  difficulty  through  conventional 
testing.  This  included  the  roll  P10  mode.  HQDT  testing 
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indicated  a  pitch  axis  control  problem  that  was  never 
seen  in  actual  PA  —  although  some  pilot  comments  did 
support  the  HQDT  results. 

6.  Pitch  sensitivity  in  aerial  refueling:  throughout 
DFCS,  the  airplane  demonstrated  a  significant  sensitivity 
in  the  pitch  axis  when  connected,  or  even  near  the  tanker. 
SCT  proposed  and  evaluated  various  control  law  modifications 
whicn  were  implemented  by  GD  to  eliminate  the  problem. 

7.  LCOS  dynamics:  SCT  devised  the  plan  used  by  the  JTF 

for  tracking  evaluations  of  AFTI  dynamics.  This  was  the 
jinking  target  superimposed  on  standard  HQDT  practice. 

The  data  generated  by  this  testing  was  used  by  SCT  to 
obtain  an  identification  of  LCOS  dynamics.  This  was 
done  using  the  frequency  response  analysis  (FRA)  program 
at  the  AFFTC.  The  resulting  identification  of  LCOS 
dynamics  was  of  very  high  quality.  This,  to  our 
knowledge,  was  the  first  time  that  fire  control  algorithm 
dynamics  were  identified  from  flight  test  data. 

8.  Identification  of  AFTI  dynamics:  SCT  played  a  principal 
role  in  stimulating  the  analysis  of  AFTI  tracking 

data  within  the  JTF  to  determine  frequency  response  models 
for  AFTI  dynamics.  SCT  also  reviewed  all  these  data  for 
the  purpose  of  quantifying  varions  flying  qualities 
behavior . 

9.  Trim  as  a  flying  qualities  parameter:  SCT  proposed  the 
use  of  trim  variations  as  a  tool  for  identifying, 
stimulating,  or  quantifying  flying  qualities  deficiencies. 
This  technique  was  successfully  used  on  one  flight  for 
characterization  of  the  pitch  sensitivity  problem  during 
refueling. 

10. In  connection  with  analysis  of  the  beta  departure 

(Flight  36),  it  was  determined  through  the  use  of  the 
AFFTC  simulation  of  AFTI  that  aircraft  dynamics  could  be 
easily  obtained  (frequency  response  form)  at  near-departure 
conditions.  The  technique  used  was  to  generate  doublet 
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responses  and  analyze  these  with  FRA.  The  results  were  of 
very  high  quality.  This  has  been  proposed  as  standard 
flight  test  practice  for  high  alpha/beta  flight  conditions. 


ANAS  Support 

Work  was  performed  in  two  distinctly  different  areas.  The  pri¬ 
mary  effort  was  for  ad  hoc  support  of  PDR  and  CDR  activities.  This 
included  reviewing  AMAS  requirements,  documentation,  pre-CDR  test 
plan,  and  attending  the  PDR  and  CDR.  With  the  completion  of  the  DFCS 
phase  of  the  flight  test  program  major  efforts  shifted  to  support  of 
the  AMAS  system  development  and  preparations  for  test  support  at  EAFB. 
The  objective  of  these  efforts,  which  are  continuing,  is  to  support 
the  overall  technical  program  of  the  AFTI/F-16  Joint  Test  Force  to 
develop  and  maintain  the  technical  competence  required  for  the  AMAS 
flight  test  program  requirements.  The  SCT  work  specifically 
addresses  the  systems  level  interactions  between  the  avionics  systems 
and  the  DFCS.  This  includes  development  of  detailed  understanding  of 
all  system  software,  hardware,  ICDs,  product  specifications,  and 
integrated  system  testing  plans  and  implementation  at  GDFW.  A  major 
portion  of  this  support  effort  has  been  dedicated  to  the  development 
of  strategies  for  safe  and  efficient  monitoring  of  AMAS  flights  and 
the  attendant  problem  of  providing  post-flight  analysis  support. 
Because  of  the  avionics-intensive  nature  of  the  AMAS  system,  it  is 
believed  that  more  accessibility  to  the  telemetry  data  stream  will  be 
required  to  provide  the  technical  support  required  by  a  modern  flight 
test  effort  of  AMAS  complexity. 

The  secondary  effort  was  initiated  very  late  in  the  program  fol¬ 
lowing  the  close-out  of  batch  simulation  activities.  The  latter 
effort  was  begun  at  NASA  DFRF  request  and  has  continued  into  FY84 
under  separate  NASA  funding.  Its  objective  is  to  develop  a  prelimi¬ 
nary  approach  to  the  methodical  design  of  fully  integrated,  redundant 
digital  flight  control  systems,  and  to  use  the  result  as  a  tool  for 
the  analysis  and  support  of  AMAS  development  and  flight  test.  Work  is 


continuing  in  preparation  for  AMAS  flight  testing.  The  developmental 
effort  which  supports  a  NASA  technology  objective  has  matured  to  a 
prototype  form,  useful  for  the  refined  resolution  of  requirements  for 
a  fault-tolerant,  distributed  processor,  integrated  control  system. 
Work  will  continue  on  this  during  early  FY84,  after  which  an  attempt 
will  be  made  to  apply  lessons  learned  to  analysis  of  the  AMAS  system. 

Documentation  Support 

SCT's  on-site  support  at  Edwards  AFB  and  NASA  DFRF  including 
maintaining  the  mass  of  program  documentation  required  for  operation 
of  a  flight  test  program.  This  effort  included  establishing  and  main¬ 
taining  the  documentation  library  of  approximately  700  reports,  with 
accession  lists  and  computer  data  base;  it  also  included  the  distri¬ 
bution  of  key  technical  reports  to  cognizant  disciplinary  engineers 
and  program  management.  Although  this  support  area  was  entirely  cler¬ 
ical,  it  was  absolutely  vital  to  the  smooth  functioning  of  the  Joint 
Test  Force.  Throughout  the  DFCS  flight  test  program,  no  time  was  ever 
lost  because  the  staff  lacked  proper  system  documentation. 

2.2.5  Conclusions  and  Recommendations 

Over  the  duration  of  this  contract  SCT  provided  support  to  the 
AFTl/F-16  Program  Office  with  the  following  activities: 

-  documentation  review 

-  design  review  report 

-  software  design  review  and  analysis 

-  digital  flight  control  system  verification 
and  analysis 

-  independent  studies  and  design  trade-offs 

-  on-site  support  including  simulation  development, 
control  system  analysis,  flight  test  support, 
and  handling  qualities  analysis. 

All  of  these  support  efforts  were  thoroughly  documented  in  weekly 
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activity  reports,  monthly  progress  reports,  and  technical  memos  issued 
as  necessary. 

As  noted  previously  in  this  report,  the  AFTI  F/16  program  is  cur¬ 
rently  in  the  AMAS  development  phase.  The  overall  complexity  of  the 
system  will  be  even  greater  than  during  the  DFCS  phase.  This  addi¬ 
tional  complexity  arises  because  several  new  techniques  are  to  be 
integrated  and  evaluated  simultaneously.  Therefore,  SCT  believes  that 
the  need  for  independent  support  is  more  acute  now  than  during  Phase 
I.  In  particular,  SCT  recommends  that  continued  support  be  sought  in 
the  following  areas: 

-  documentation  review 

-  mechanization  document 

-  test  plans  and  procedures 

-  software  design  assessment 

-  design  review  participation 

-  software  test  procedure  and  results  auditing 

-  independent  studies 

-  system  wide  integrity  management  (SWIM)  implementation 

-  AMAS  performance  assessment 

-  on-site  support 

-  AMAS  simulation 

-  handling  qualities  evaluation 


2.3  TRANSPORT  ADVANCED  CONTROL  SYNTHESIS  (TRACS) 


2.3.1  Program  Background  and  Goals 

The  emphasis  of  the  TRACS  program  is  to  demonstrate  advanced  con¬ 
trol  synthesis  applications  for  transport  aircraft  and  to  evaluate  the 
feasibility  of  crew  station  integration  concepts.  The  TRACS  program 
is  comprised  of  four  main  activities,  namely,  (1)  flight  trajectory 
investigation,  (2)  throttle/energy  management,  (3)  transport  advanced 
control  technology  and  (4)  tanker  integration  and  evaluation.  A 
representation  of  the  relationship  of  these  areas  and  various  programs 
within  each  of  them  is  shown  in  Figure  2.3-1.  The  flight  test  bed  to 
demonstrate  the  post-1980  military  transport  mission  is  the  Speckled 
Trout  (C135-C)  aircraft  which  is  equipped  with  a  digital  flight  con¬ 
trol  system  (Sperry),  advanced  displays,  and  a  number  of  inertial/area 
navigation  (Collins)  systems.  Flight  control  performance  improvements 
have  been  demonstrated  by  incorporation  of  digital  systems.  Analysis 
and  applications  of  integrated  throttle/flight  path  control  techniques 
enable  a  pilot  or  automatic  control  system  to  regulate  an  aircraft's 
potential  and  kinetic  energy.  The  TRACS  program  has  utilized  a  sys¬ 
tematic  design  approach  to  systems  integration  investigations  of 
controls/displays/sensor  s/pilot  to  provide  the  potential  for  increas¬ 
ing  operational  mission  performance. 

2.3.2  Work  Accomplished 

The  tasks  performed  fall  into  four  areas:  Software  Acceptance 
Review,  Flight  Control  Law  Analysis,  Simulation/Validation  Facility 
Development  Support,  and  Flight  Control  Test  Support. 
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Figure  2.3-1  Transport  Advanced  Control  Synthesis  (TRACS)  Program 


2 . i . 2 . 1  Digital  Flight  Guidance  System  (DFGS)  Software 
Acceptance  . review 

SCT  provided  support  to  FIGL  in  receiving,  reviewing  and  docu¬ 
menting  the  Sperry  1819B  computer  and  associated  software.  The 
activity  included  providing  documentation  of  the  system  and  generation 
of  recommendations  of  additional  features  to  enhance  system  capabili¬ 
ties.  The  effort  required  review  of  the  avionics  software  provided 
and  associated  support  software  used  for  software  modification,  simu¬ 
lation  and  flight  analysis.  As  a  result  of  the  software  review,  a 
number  of  system  enhancements  were  identif ied/recommended. 

Central  to  the  following  discussion  of  system  enhancements  to 
improve  development  and  validation  efficiency,  more  memory  capability 
is  required  in  the  DFGS  system.  The  basic  system  utilizes  16K  core 
memory  and  is  operated  in  the  Speckled  Trout  in  that  configuration. 
The  system  currently  supports  only  minimal  digital  data  recording 
capability  and  requires  significant  software  modification  and  auxili¬ 
ary  memory  to  support  ground-based  simulation.  The  basic  avionics 
system  should  include  32K  core  memory.  The  additional  memory  would 
allow  for  basic  system  enhancements,  simulation  and  research  inter¬ 
faces,  enhanced  utility  capability  and  implementation  of  alternate 
research  algorithms.  The  software  should  be  modified  to  provide  skip 
key  control  of  the  simulation  and  research  options  similar  to  systems 
developed  by  Sperry  for  the  Stoland  and  V/Stoland  for  Ames  Research 
Center . 

RECOMMENDATIONS/ CONC  LUS IONS  -  During  software  development  and 
checkout,  it  is  recommended  that  each  change  to  the  system  be  accom¬ 
panied  with  software  engineering  documentation.  The  documentation 
should  include  the  reason  for  the  software  change  and  the  implementa¬ 
tion  method  used  to  incorporate  the  change.  If  a  new  assembly  was 
performed,  the  listing  and  variable  cross  reference  table  should  be 
provided.  In  any  event,  some  form  of  mnemonic  listing  should  be  pro¬ 
vided.  Associated  with  each  software  change,  a  detailed  flight  plan 
(or  simulator  study)  should  be  generated  to  validate  each  revision 
incorporated. 

•  Digital  Data  Recording  -  It  is  recommended  that  the  number  of 
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variables  recorded  be  increased  to  at  least  80  by  either  increas¬ 
ing  the  size  of  the  data  buffer  transferred  or  by  multiplexing 
methods.  Engage  mode  status  words,  packed  discretes  and  monitor- 
ing-valid  words  should  be  recorded.  A  recommended  enhanced  data 
list  where  the  time  tagging  of  the  data  is  assumed  to  be  appended 
during  PCM  recording  was  provided  to  the  Air  Force. 

•  Keyboard  Gains  -  A  table  of  keyboard  gains  was  presented  which 
should  be  adjustable  inflight  to  50-200%  nominal  value. 

•  Aircraft  Simulation  Facility  -  It  is  recommended  that  a  ground 
based  simulator  be  developed  to  allow  adequate  analysis  and  reso¬ 
lution  of  current  system  anomalies.  A  simulator  could  be  used 
for  testing  alternative  control  system  gain  strategies  or  dupli¬ 
cating  anomalies  found  in  flight  testing  in  a  controlled 
environment . 

2. 3. 2. 2  DFGS  Flight  Control  Law  Analysis 

This  i_ask  examined  the  performance  of  the  Digital  Flight  Guidance 
System  (DFGS)  software.  Testing  and  analysis  of  the  DFGS  software  was 
performed  so  as  to  assist  FIGL  in  analyzing  DFGS  software  performance. 
This  software  testing  was  augmented  by  reviewing  documentation  of  pre¬ 
viously  performed  stability  analysis  and  by  performing  additional 
linear  analysis. 


System 


Preliminary  identification  of  anomalies  in  the  KC135  Speckled 
Trout  Digital  Flight  Guidance  System  has  resulted  in  a  detailed  des¬ 
cription  of  the  lateral  control  system  to  permit  a  more  informed 
selection  of  control  system  gains.  The  full  report  was  given  to  the 
Air  Force.  The  KC135  aircraft  itself,  without  any  stability  augmenta¬ 
tion,  is  inherently  lightly  damped  in  its  dutch-roll  response.  During 
program  development,  system  validation,  using  a  ground-based  simulator 


was  performed.  The  aircraft  model  used  in  the  validation  was  approxi¬ 
mate  and  a  more  accurate  model  is  now  available.  In  addition,  during 
the  development  of  the  control  systems  and  preliminary  flight  testing, 
considerable  program  modification  has  been  performed.  Since  simula¬ 
tion  facilities  are  not  available,  a  linear  analysis  approach  was 
utilized  to  assist  in  the  evaluation  of  the  existing  lateral  system. 

RECOMMENDATIONS/ CONCLUS IONS 

-Adjust  KYAWRT  according  to  root  locus  analysis  and 
evaluate  performance. 

-The  feed-forward  component  of  the  rudder  control 
system,  not  presently  used,  could  be  modified  to  provide 
an  aileron  displacement  component.  The  adjustable 
feed  forward  gain,  KYAWFF,  could  be  used  to  incrementally 
incorporate  the  effect  in  the  control  system  during 
evaluation. 

-Establish  a  specific  data  list  to  diagnose  the  rudder  and 
aileron  control  systems.  Major  components  of  the  control 
commands  should  be  recorded  along  with  mode  control  flaps. 
Recommended  variables  include:  ZTW02,  YAWRRF ,  YAWRCF, 
and  YDENGF . 


DFGS  Autothrottle  Analysis 

Pilots  of  the  Speckled  Trout  aircraft  expressed  dissatisfaction 
with  the  autothrottle's  performance  at  low  altitudes  and  Mach  numbers 
of  0.3  and  less.  Therefore,  a  representative  flight  condition  was 
chosen  as  the  basis  for  this  study,  the  coupled  airframe-engine-pitch 
control-autothrottle  system  was  simulated,  and  changes  in  the  values 
of  autothrottle  gains  and  minor  changes  in  the  autothrottle  design 
were  investigated  for  improved  performance. 

The  autothrottle  and  its  environment,  i.e.,  its  interaction  with 
the  longitudinal  aerodynamics  of  the  airframe,  the  engine  thrust 
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acceleration  and  deceleration  dynamics,  the  pitch  control  loop,  and 
the  control  servomechanisms  were  analyzed. 

Initially  it  was  hoped  that  a  linear  analysis  of  the  system  would 
be  possible,  for  then  tools  such  as  root-loci  plots  and  eigensystem 
analysis  could  be  applied.  However,  it  was  soon  evident  that  some 
components  of  the  coupled  system  could  not  be  represented  adequately 
by  linear  differential  equations.  This  is  particularly  true  of  the 
engine  thrust  acceleration  dynamics  and  the  digital  logic  of  the 
autothrottle  and  pitch  control.  Hence,  it  was  necessary  to  resort  to 
developing  a  simulation  of  the  system  and  to  study  the  time-history 
response  directly.  This  approach  was  further  necessitated  because  a 
Speckled  Trout  simulator  with  the  DFGS  software  operating  in  an  1819B 
computer  was  not  available. 

The  nature  of  this  study  is  necessarily  qualitative  since/  first, 
flight  data  on  autothrottle  variables  in  the  form  of  strip  charts,  for 
example,  was  not  available,  and  second,  what  constitutes  good 
autothrottle  performance  is  partly  a  subjective  judgement. 

RECOMMENDATIONS/ CONCLUS IONS 

Of  the  six  autothrottle  gains  which  were  varied  to  study  their 
influence  on  performance  at  a  specific  flight  condition,  two  showed 
promise  for  improving  the  response.  Of  these  two,  the  better  improve¬ 
ment  was  shown  by  decreasing  the  time  constant  of  the  lag  element 
whose  output  leads  to  the  throttle  command  THRCMD.  In  the  DFGS 
software,  this  means  increasing  the  value  of  the  eleventh  element  of 
the  array  ZFGEAA,  whose  present  value  is  0.00631  corresponding  to  a 
time  constant  of  8  seconds.  For  a  desired  time  constant  of  T  , 
this  value  should  be  changed  to 

l_e--05/x 

Lesser  improvement  to  the  autothrottle  response  results  if  the 
gain  KT1P8  is  increased  (i.e.,  made  more  negative).  Its  present  value 
is  -1.8.  One  side  effect  of  such  a  change  was  to  shorten  the  period 
of  the  outer-loop  autothrottle  oscillations,  which  is  judged  undesir- 
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able. 


The  minor  software  change  of  including  a  gain  greater  than  one  on 
the  velocity  rate  input  also  produced  improved  response.  However,  if 
the  velocity  rate  is  noisy,  performance  would  be  degraded  through  the 
amplification  of  this  noise.  It  is  recommended  that  the  changes  des¬ 
cribed  above  be  tried  in  the  order  presented. 

2. 3. 2. 3  Simulation/Validation  Facility  Development  Support 

The  objectives  of  this  task  were  three-fold: 

•  Take  the  initial  steps  for  facility  layout  and 
integration  with  other  equipment  in  the  Digital 
Synthesis  Flight  Engineering  Facility  (FEF) , 

Bldg.  145. 

•  Explore  the  use  of  an  AN/AYK-15  and  1553  data  bus  to 
implement  the  Flight  Control  Research  Computer 

( FCRC)  and  communication  function  with  the  Sperry 
DFGS. 

•  Implement  the  previously  developed  Speckled  Trout 
aerodynamic  model  (with  simplified  throttle  and 
engine  models)  on  the  FEF  PDP-11  computers. 

In  the  absence  of  a  Sperry  1919B  computer,  facility  lay-out  and 
integration  had  to  be  performed  in  a  preliminary  way.  This  was  accom¬ 
plished  using  an  AN/AYK-15  computer  to  "model"  the  Sperry  computer. 

A  second  AN/AYK-15  was  used  to  represent  the  FCRC.  A  Universal 
Remote  Terminal  (URT)  interfaced  the  1553A  bus  with  a  PDP-11/34,  where 
the  aircraft  equations  of  motion  resided.  Sensor  data  and  actuator 
commands  constituted  the  information  flowing  in  and  out  of  the  EOM 
over  a  1553A  bus. 

To  demonstrate  that  this  configuration  was  workable,  SCT  first 
loaded  the  Sperry  1819B  model  with  guidance  and  control  software  and 
repeated  a  selected  guidance  algorithm  in  a  second  processor,  the 
FCRC.  SCT  then  implemented  software  to  effect  the  following  sequence: 


1.  Sperry  1819B  model  feeds  Guidance  input  data  to 
FCRC  model. 

2.  FCRC  model  computer  its  Guidance  law. 

3.  Sperry  1819B  model  receives  FCRC  Guidance  command 
(previous  pass) . 

4.  Sperry  1819B  model  computer  Control  Law  command 
based  on  FCRC  Guidance  Input. 

In  the  above  demonstration,  models  were  needed  for  aircraft  guidance 
and  control  laws  and  also  for  a  consistent  airframe  to  be  controlled. 
Although  SCT  had  implemented  a  KC-135  aircraft  model  on  the  PDP-11/34, 
a  set  of  compatible  guidance  and  control  law  algorithms  which  could  be 
run  on  an  AN/AYK-15  did  not  exist.  For  this  reason,  the  existing  A-7D 
guidance  and  control  laws,  along  with  an  A-7D  aircraft  model,  were 
used  for  this  demonstration.  Conversion  to  the  Speckled  Trout  EFGS 
and  aircraft  model  can  be  accomplished  in  accordance  with  the  plan 
presented  below. 


The  following  points  summarize  the  work  accomplished: 

1.  The  integration  of  the  Sperry  1819B  with  a  AN/AYK-15 
appears  feasible. 

2.  Two  AN/AYK-15' s  and  a  PDP-11/34  with  aircraft  model 
are  in  place. 

Hardware  and  software  work  must  be  accomplished  to  integrate  a 
working  facility  appropriate  to  the  Speckled  Trout.  This  work  may  go 
in  either  of  two  directions.  One  approach  is  to  begin  integrating  the 
system  according  to  the  following  steps: 

1.  Design  and  fabricate  Sperry/1553  interface  box  —  FEF 
support  group. 

2.  Have  Sperry  train  Air  Force  personnel  (FEF  support  group 
or  contractors)  on  microprogramming  of  I/O  channels. 

3.  Develop  interface  software  for  basic  Sperry  AN/AYK-15 
communication  over  1553  bus. 


4.  Restructure  Sperry  DFGS  and  accomplish  functional 

integration  with  FCRC  (AN/AYK-15  applications  software) . 

Alternatively,  if  the  facility  is  to  be  ground-based  for  more  time  and 
if  it  is  to  be  used  for  algorithm  analysis  (rather  than  flight 
software  verification),  we  would  recommend  considering  a  different 
approach.  This  approach  is  to  develop  a  moderate  fidelity, 
all-software  model  of  the  Sperry  DFGS  and  implement  it  on  one  of  the 
AN/AYK-15's.  Research  algorithms  can  be  developed  and  run  in  parallel 
on  the  other  AN/AYK-15.  All  interface  communication  can  be  done  over 
the  1553  bus,  including  interface  to  the  Speckled  Trout  aircraft 
model.  Note  that  this  could  be  a  fairly  low-cost  approach,  because 
all  the  hardware  is  in  place  and  the  system-level  exec/bus  control  is 
already  working.  Also,  the  Speckled  Trout  aircraft  is  already  work¬ 
ing.  Also,  the  Speckled  Trout  aircraft  model  has  been  made  compatible 
with  the  FEF  PDP-11/34.  The  major  work  element  is  the  recoding  of  the 
DFGS  in  Jovial  to  run  on  an  AN/AYK-15. 

2. 3. 2. 4  Flight  Control  Test  Support 

The  objective  of  this  task  was  to  formulate  a  strawman  flight 
test  plan  for  the  Speckled  Trout  aircraft.  The  plan  was  coordinated 
with  FIGL  to  be  consistent  with  research  objectives  in  the  FY80-FY81 
time  frame.  The  plan  covered  the  following: 

•  Eligfat  lest  Obis.gtuiY.fig  and  simulation  Reguixements 
Summary  -  Background  material  on  example  objectives 
for  the  collection  of  flight  test  data  and  development 
of  a  Speckled  Trout  simulation  model  of  reasonable 
fidelity. 

•  Air  ox  aft  Modeling  and  Systems  Identification  - 

An  overview  of  the  overall  systems  identification 
methodology,  with  examples  extracted  from  work  done 
previously  for  the  Office  of  Naval  Research  using 
the  F-4S  and  T-2C  aircraft. 
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•  Speckled  Trout  Aircraft  Instrumentation  -  A 
description  of  the  current  Speckled  Trout  data 
collection  system,  and  recommended  enhancements  for 
systems  identification. 

•  Recommendtions  fj 2L  Preliminary  FligM  Test  Plan  - 
Recommendations  for  an  initial  set  of  test  conditions, 
test  inputs,  and  data  recording  requirements  to 
generate  a  set  of  preliminary  data. 

As  a  result  of  this  study,  specific  inputs  to  a  preliminary 
flight  test  plan  for  system  identification  of  the  Speckled  Trout  air¬ 
craft  were  presented  and  summarized  below.  These  inputs  include  a 
definition  of: 

(1)  Aircraft  Configuration/Flight  Conditions 

(2)  Recommended  Maneuvers 

(3)  Data  Recording  Requirements 


For  this  preliminary  plan,  the  maneuvers  focus  on  identifying  the 
basic  aircraft  model  in  a  cruise  condition.  This  is  done  because  it 
corresponds  to  the  least  complicated  aircraft  configuration,  and  thus 
is  the  simplest  illustration  of  the  system  identification  procedure. 
Also,  the  bulk  of  existing  modeling  data  is  oriented  towards  the 
cruise  condition  so  that  comparisons  can  readily  be  made.  Basically, 
technical  risk  is  minimized  with  this  approach. 

Flight  test  planning  is  always  in  iterative  process.  As  the 
objectives  change  and  as  deficiencies  are  discovered  in  the  flight 
data,  revisions  to  the  flight  test  plan  can  be  expected.  In  particu¬ 
lar,  the  next  step  in  the  system  identification  and  modeling  process 
will  be  to  focus  on  specific  simulation  model  update  requirements  and 
broaden  the  flight  test  scope  to  include  the  approach/landing  configu¬ 
ration.  At  that  time,  additional  maneuvers  will  be  specified  to  study 
ground  effect,  pitch  moment  due  to  thrust  changes,  effect  of  flaps  and 
spoilers,  etc. 

Note  in  the  following  that  an  attempt  was  made  to  make  the  data 
recording  requirements  to  be  sufficiently  general  so  as  not  to  require 
modification  for  future  identification  flight  tests. 


RECOMMENDATIONS/ CONCLUS IONS 


Aircraft  Configuration/Flight  Conditions 

The  aircraft  should  be  established  in  its  normal  cruise  configu¬ 
ration.  The  autopilot  should  be  disengaged,  except  as  necessary  to 
support  recording  requirements  via  the  Honeywell  RL-6.  The  yaw  dumper 
should  be  disengaged,  except  as  specified  by  particular  maneuvers. 

Prior  to  flight,  center- of-gravity  location  should  be  measured, 
and  all  mass  properties  recorded. 

Flight  conditions  should  include  cruise  at,  as  a  minimum,  two 
altitudes  (e.g.,  hi  =  30K  ft,  and  h2  =  20K  ft).  The  throttle  should 
be  held  constant  at  normal  cruise  setting.  The  recommended  maneuvers 
reported  assume  an  initiation  from  trimmed  cruising  flight  at  the  two 
specified  initial  altitudes.  However,  precisely  trimmed  initial  con¬ 
ditions  are  not  required  for  the  system  identification  analysis. 

RECOMMENDED  MANEUVERS 

An  initial  set  of  maneuvers  suitable  for  system  identification 
for  cruising  flight  were  detailed  in  a  table.  The  table  lists  the 
maneuver  number,  title,  identification,  objective,  and  a  description 
of  manual  inputs.  As  a  minimum,  two  cruise  angl es- of - attack  should  be 
flown  (e.g.f  =  3  deg,a2  =  7  deg). 

The  following  points  are  notable  from  the  information  provided  in 
the  table: 

(1)  A  "square  wave"  input  is  preferred  because  it  excites 
a  broader  band  of  frequencies  than  other  inputs  (step, 
sine  wave) . 

(2)  Several  amplitudes  and  frequencies  of  inputs  should  be 
tried. 

DATA  RECORDING  REQUIREMENTS 

The  variables  which  should  be  recorded  to  support  system  identif¬ 
ication  were  also  listed  in  the  table.  It  is  recognized  that  when  the 
Sperry  Autopilot  is  not  engaged,  certain  of  these  variables  may  be 
meaningless  (e.g.,  PHICOM,  etc.)  However,  means  must  be  provided  to 
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record  sensor  data  via  the  Sperry/Honeywell  RL-6  regardless  of  autopi¬ 
lot  mode. 

Note  also  that  recording  mechanisms  must  be  developed  for 
angles-of-attack  and  sideslip  and  pertinent  engine  parameters  (Items 
33  through  50  in  the  table) .  In  lieu  of  direct  measurements,  a  and 
rf  could  be  calculated  from  NAV  parameters: 

a  =  h  1  VTAS 
^  =  ^  "  ^REL  WIND 

However,  this  would  require  NAV  data  at  10-20  SPS.  H  would  have  to 
come  from  the  Sperry  complementary  altitude  filter  and  VTAS  also  from 
Sperry  autopilot  calculations.  V  REL  WIND  would  have  to  be  calculated 
from  quantities  supplied  by  the  RNAV  system.  All  these  calculations 
subject  the  a  and  &  estimates  to  errors;  thus  raw  measurements  are 
much  preferable. 


2.4  FLIGHT  CONTROL  DEVELOPMENT  LABORATORY  ( FCDL ) 


Under  the  ICSES  contract,  Systems  Control  Technology,  Inc. 
provided  support  to  the  Air  Force  Wright  Aeronautical  Laboratories 
Flight  Dynamics  Laboratory  Control  Synthesis  Branch  (AFWAL/FIGD)  in 
the  areas  of  establishing  a  software  management  methodology  and 
software  tools  to  implement  this  methodology.  The  Flight  Control 
Development  Laboratory  provides  the  developmental  tools  to  advance 
flight  technology  and  ensures  that  future  Air  Force  weapon  systems 
will  be  less  costly,  more  survivable,  and  have  superior  performance 
characteristics.  Cost-effective  development  of  advanced  aircraft  is 
enhanced  through  simulation  testing.  Engineering  flight  simulation  is 
achieved  by  mathematically  modeling  an  aircraft  using  aerodynamic, 
flight  control,  propulsion,  structural,  avionic,  and  environmental 
characteristics  coupled  with  the  necessary  displays  and  a  control  feel 
system  which  enables  the  pilot  to  experience  the  illusion  of  actual 
f 1 ight . 

The  Flignt  Control  Development  Laboratory  contains  a  number  of 
simulation  facilities  including  the  LAMARS,  Multicrew  Simulator, 
Fighter/Bomber  Simulator,  Crew  System  Integration  Facility,  Flight 
Control  Actuation  and  Hydraulics  System  Facility,  and  two  in-flight 
simulators  (T-33  In-Flight  Simulator  and  the  Total  In-flight  Simula¬ 
tor)  . 

The  Large  Amplitude  Multimode  Aerospace  Research  Simulator 
(LAMARS)  consists  of  a  f ive-degr ee-of  freedom  beam  type  motion  system 
which  carries  a  single-place  cockpit  and  display  screen  on  the  end  of 
a  30-foot  beam.  The  motion  base  produces  motions  at  the  pilot's  sta¬ 
tion  in  precise  phase  and  amplitude  corresponding  to  the  signals  under 
computer  control.  The  on-board  visual  display  system  utilizes  a  wide 
angle,  ten-foot  radius,  spherical  projection  screen  that  provides  the 
pilot  with  a  visual  representation  of  the  outside  environment.  The 
cocxpit  design  is  compatible  with  all  modern  fighter  aircraft  configu¬ 
rations  and  can  be  readily  adapted  to  different  configurations. 

The  Multicrew  Simulator  and  Fighter/Bomber  Simulator  are  also 
motion  base  systems.  The  cockpit  controls,  configuration,  and  in¬ 
strumentation  may  be  readily  modified  as  required.  The  control  feel 
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system,  with  either  a  wheel/column  or  center  stick  can  be  programmed 
with  desired  characteristics.  Both  systems  carry  a  DUOVIEW  visual 
display  system  to  enhance  the  realism  of  the  simulation  task.  Both 
cockpits  have  multi-degree  of  freedom  scissors  type  motion  systems. 
The  Multicrew  Simulator  has  three  degrees  of  freedom:  pitch,  roll  and 
heave.  The  Fighter/  Bomber  Simulator  has  five  degrees  of  freedom, 
adding  lateral  translation  and  yaw  to  the  three  previously  mentioned. 

A  Rigid  Model  Visual  System  (RMVS)  is  also  used  which  consists  of 
illuminated  three-dimensional  terrain  models,  each  with  an 
optical-probe-equipped  television  camera  positioned  by  precision  servo 
systems  commanded  by  computer  control.  The  LAMARS,  Multicrew,  and 
Fighter/Bomber  Simulators  all  make  use  of  this  RMVS. 

A  hybrid  computing  system  forms  the  nucleus  of  the  simulation 
equipment  and  consists  of  digital  and  analog-computers.  i’he  computing 
system  also  has  peripheral  equipment  including  card  readers,  line 
printers,  terminals,  magnetic  tape  units,  and  eight-channel  recorders 
and  x-y  plotters.  A  summary  of  this  computing  system  is  shown  in  Fig¬ 
ure  2.4-1. 

The  Crew-System  Integration  Facility  contains  static  crew  station 
models  that  provides  a  cost-effective  means  for  determining  design 
criteria  such  as  crew  size,  control  and  display  arrangement,  display 
formats,  and  crew  procedures. 

The  Flight  Control  Actuation  and  Hydraulics  System  Facility  con¬ 
tains  equipment  used  to  develop  and  test  servoactuator  that  provide 
the  essential  link  Detween  cockpit  controls  and  aircraft  control  sur¬ 
faces  . 

The  T-33  In-Flight  Simulator  and  the  Total  In-Flight  Simulator 
provide  an  element  of  realism  to  simulation  which  is  impossible  to 
obtain  in  ground  based  simulation  activities.  In-flight  simulation 
can  provide  realistic  sustained  motion  cues  and  an  outside  visual 

scene . 


2.4.1  Support  Requirements 


The  evolution  of  the  FCDL  is  not  unlike  that  of  many  other  simu- 
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lation  facilities,  and  common  problems  can  be  seen  to  have  arisen. 
Today,  the  FCDL  serves  a  number  of  varied  users,  ranging  from  inhouse 
activities,  to  other  FDL  groups  (ADPO's,  etc.),  to  nonmilitary  users 
such  as  the  F.A.A.  Simulations  are  developed  to  represent  a  number  of 
different  aircraft  performing  increasingly  complex,  multi-role  mis¬ 
sions.  Expansion  and  modernization  of  hardware  and  related  software 
happen  on  a  continuing  basis.  Software  and  hardware  interface 
requirements  between  different  programs  may  be  implemented  differently 
by  design  or  by  necessity.  Software  of  many  types  (real-time  simula¬ 
tion  models,  off-line  support  software,  post-run  data  reduction 
software,  etc.)  had  proliferated  to  the  point  where  FIGD  did  not  know 
exactly  what  software  existed  or  how  it  might  be  reused.  Software 
maintenance  was  difficult,  including  both  the  long-term  ability  to 
retrieve  archival  programs  for  re-use  and  also  the  continual  mainte¬ 
nance  of  current  systems  on  a  systematic  basis.  Personnel  turnover 
further  complicated  these  problems  in  that  it  was  difficult  for  new 
personnel  to  absorb  the  simulation  development  techniques  and  their 
unawareness  of  software  which  already  existed  caused  much  duplication 
of  effort.  Many  of  these  problems  could  be  traced  to  inadequate  con¬ 
trol  of  the  software  development  process  and  the  resulting  absence  of 
adequate  documentation.  Since  particular  software  management  require¬ 
ments  vary  from  facility  to  facility,  an  in-depth  examination  of  the 
FCDL  software  development  methods  was  performed  by  talking  with  num¬ 
erous  FCDL  personnel.  The  information  collected  in  these  interviews 
was  integrated  into  the  following  areas:  software,  firmware/hardware, 
configuration  control,  project  management,  training/indoctrination, 
customer  interaction,  and  vendor  interaction. 

Each  of  these  problem  areas  were  then  mapped  in  requirements  to 
be  addressed  in  the  ensuing  development  of  a  software  management 
methodology.  This  entire  analysis  is  contained  in  SCI  Document 
#80-FCDL-09  Rev.  A,  "Software  Management  Methodology  Requirements 
Analysis",  30  June  1980.  A  summary  of  the  identified  requirements  is 
presented  below. 

Project  Management  Requirements 

Establish  project  management  practices  and  procedures  which  will: 
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perform  the  simulation  development  effort  in  the  most  direct,  effi¬ 
cient  and  controllable  manner;  provide  short  clear  lines  of 
communications;  permit  concentration  of  the  appropriate  technical 
skills;  provide  complete  visibility  to  FIGD  management  throughout  the 
development,  test,  and  integration  phases.  In  short,  project  manage¬ 
ment  involves  all  facets  of  simulation  development,  establishing 
guidelines,  managing  and  coordinating  activities,  and  insuring  the 
program  requirements  are  met  in  an  expeditious  manner. 

Software  Development  Requirements 

Establish  software  development  methods  and  procedures  that  will 
produce  accurate,  efficient,  readable,  maintainable,  and  well  docu¬ 
mented  software  programs.  These  methods  and  procedures  will  address 
software  development  from  the  requirements  phase  through  validation 
and  applications. 

md&ct la nation  and  Training  Requirements 

Establish  the  mechanism  for  indoctrination  and  training  of  per¬ 
sonnel  in  regards  to  the  software  management  methodology.  This  may 
include  recommendations  for  vesting  particular  parts  of  the  FIGD 
organization  with  the  authority  and  responsibility  to:  develop  pro¬ 
cedures  to  indoctrinate  personnel  in  task  management,  configuration 
management  and  developmental  standards;  train  new  personnel  in  the 
use  of  configuration  management  library  and  other  technical  resources; 
develop  instructional  material  in  applicable  software  engineering 
practices . 

Configuration  Management  Requirements 

Establish  configuration  management  procedures  which  will  (a) 
identify  and  document  the  functional  and  physical  characteristics  of 
the  simulation  software;  (b)  control  changes  to  those 
characteristics;  and  (c)  record  and  report  change  processing  and 
implementation  status.  In  particular,  the  procedures  should  address: 
configuration  management  organization  and  authority  for  software  con¬ 
trol;  establishment  of  a  configuration  management  (CM)  plan  which 
implements  CM  organization,  library  and  resouces  in  a  phased  manner; 
establishment  of  configuration  control  procedures;  status  accounting 
of  all  controlled  items;  procedures  for  review  and  audit;  guidelines 
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and  procedures  for  managing  obsolete  software  in  the  CM  library; 
procedures  for  deciding  what  software  is  subject  to  CM,  and  which  is 
not;  and  identification  of  product  support  software  needed  to  imple¬ 
ment  fast,  responsive  configuration  management. 

2.4.2  Work  Accomplished 

Having  performed  requirements  analysis  to  identify  the  type  of 
support  which  would  best  meet  the  needs  of  FIGD,  a  two  phased  effort 
was  defined  to  meet  these  requirements.  The  two  phases  were  (1) 
development  of  Software  Management  Methodology  and  (2) 
design/development  of  software  tools  for  support  of  this  methodology. 

2. 4. 2.1  Software  Management  Methodology 

A  software  management  methodology  was  developed  which  addressed 
all  aspects  of  software  development,  from  initial  software  planning  to 
software  control  and  maintenance.  This  methodology  was  presented  in 
four  separate  volumes  of  software  standards,  consisting  of  Software 
Management  Standards,  Software  Development  and  Test  Standards, 
Software  Documentation  Standards,  and  Software  Configuration  Manage¬ 
ment  Standards. 

Standardization  of  software  management  is  necessary  to  achieve 
the  following  objectives: 

•  Reduce  resource  expenditures  in  software  development 

•  Improve  software  development  resource  estimating 

•  Avoid  duplicate  software  development  efforts 

•  Improve  quality  of  software 

•  Reduce  software  maintenance  efforts 

A  disciplined  software  development  process  can  be  broken  into 
three  phases:  Preliminary  Design  Phase,  Detailed  Design  Phase,  and 

Implementation  and  Test  Phase.  These  phases  are  depicted  in  Figure 
2.4-2.  These  three  phases  follow  naturally  from  the  activities  per¬ 
formed  in  the  development  of  any  software  product.  Each  phase 
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contains  milestones  used  by  management  as  breakpoints  to  monitor  and 
review  the  progress  of  the  development  effort.  Within  each  of  these 
phases  specific  activities  are  defined  and  specific  outputs  are  pro¬ 
duced  which  allow  both  managerial  and  technical  review  of  the  software 
development  (see  Figure  2.4-2). 

During  the  Preliminary  Design  Phase,  a  software  development  plan 
is  written,  the  software  requirements  are  defined,  external  interfaces 
are  identified,  a  conceptual  software  design  is  achieved  and  a  plan 
for  testing  simulation  software  against  requirements  is  written. 
Within  this  phase,  all  performance  and  external  interface  requirements 
are  documented  prior  to  the  conceptual  software  design  and  are 
reviewed  at  a  Software  Requirements  Review  (S/WRR) .  The  conceptual 
design  and  test  plan  are  documented  during  this  phase  and  reviewed  at 
a  Preliminary  Design  Review  ( PDR) . 

The  Detailed  Design  Phase  starts  after  the  PDR.  During  this 
phase,  interfaces  between  all  simulation  software  components  are 
defined  in  detail,  the  software  components  are  designed  and  document¬ 
ed,  and  preparations  for  integration,  system,  and  presimulation 
testing  are  initiated.  The  documents  prepared  are  then  reviewed  at  a 
Critical  Design  Review  (CDR) . 

During  the  third  phase,  Implementation  and  Test,  computer  program 
code  is  written  and  checked  individually  and  then  integrated  to  form 
t:.e  simulation  software.  Test  procedures  for  development  testing  are 
documented  and  reviewed  at  the  Test  Procedures  Review.  During  test¬ 
ing,  test  results  are  documented  as  required,  instructions  for 
operating  the  simulation  are  documented,  plus  a  list  of  the  simulation 
hardware  and  software  is  prepared.  A  summary  of  the  software  mile¬ 
stones  and  related  activities  is  shown  in  Figure  2.4-3. 

The  software  standards  which  were  prepared  can  be  applied  to  the 
development  of  any  size  software  program,  but  have  been  tailored  to 
meet  the  needs  of  the  FIGD  software  development  team.  As  shown  in 
Figure  2.4-4,  the  Software  Management  Standards  control  the  use  of  the 
Software  Development  and  Test  Standards  and  Software  Configuration 
Management  Standards.  Application  of  the  Software  Development  and 
Test  Standards  yields  software  products  which  conform  to  quality 
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PDR  to  CDR 
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CDR  to  TPR 
Coding 

Unit  and  Module  Testing 
Integration  Testing 
Design  Change  Control 
Operating/Version  Document  Update 

Software  Test  Document  Update  Test  Procedures  Review 


TPR  to  SAR 


System  Testing 

Release  of  Software  Documentation 
Presimulation  Validation 
Software  Development  Evaluation 
Records  Disposition 
Simulation  Maintenance 


Simulation  Acceptance  Review 


Figure  2.4-3  Software  Development  Activities 
and  Milestones 
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Figure  2.4-4  Software  Standards 


assurance  provisions  and  controls  established  by  the  Software  Configu¬ 
ration  Management  Standards.  The  Software  Documentation  Standards 
establish  the  format  and  content  of  the  four  milestone  documents. 
Each  of  the  software  standards  is  summarized  below. 

SQf.tw.aua  Management  standards 

The  Software  Management  Standards  provides  FIGD  software  managers 
with  procedures  and  guidelines  for  planning  and  managing  simulation 
software  development. 

The  standards  describe  the  duties  and  responsibilities  associated 
with  each  function  performed  by  the  software  development  team  during 
each  phase  of  software  development.  The  management  standards  contain 
a  description  of  the  software  development  process  and  a  summary  of  all 
software  standards. 

Software  Development  and  Test  Standards 

The  Software  Development  and  Test  Standards  provide  engineering 
and  programming  guidelines  to  preliminary  design,  detailed  design,  and 
implementation  and  test  activities.  These  standards  describe  the 
activities  to  be  performed  during  each  development  phase.  Activities 
described  are  simulation  software  requirements  definition,  conceptual 
design,  detailed  design,  coding,  checkout,  and  testing.  These  stan¬ 
dards  also  describe  the  tools  and  techniques  that  are  used.  Examples 
of  tools  and  techniques  are:  flow  charts,  data  flow  diagrams,  pro¬ 
gramming  languages,  and  data  base  dictionaries. 

Software  Documentation  Stan.d.ai-da 

The  Software  Documentation  Standards  provide  formats  and 
guidelines  for  four  documents  required  in  the  software  development 
process. 

The  documents  to  be  produced  for  each  software  development  have 
three  main  purposes: 

•  To  provide  information  for  communication  and  management 
control  of  the  entire  development  process. 

•  To  provide  baselines  for  further  development  and 
maintenance  of  the  software. 

•  To  provide  evidence  at  all  stages  of  the  process  that 
the  software  being  developed  meets  specific  functional 
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requirements  and  schedules. 


Each  of  the  4  software  documents  addresses  particular  documenta¬ 
tion  requirements  as  follows: 

1.  Software  Requirements  Specification:  Specifies  the 
functional,  performance,  external  interface,  and 
design  requirements  for  the  simulation  software  to 
be  developed. 

2.  Software  Design  Specification:  Specifies  the  simulation 
software  design  including  all  internal  interfaces  and 
module  detailed  design. 

3.  Software  Test  Document:  Presents  a  simulation  software 
test  plan,  test  procedures,  and  test  report  for  the 
different  levels  {module,  integration,  system,  and 
presimulation  validation)  of  software  testing. 

4.  Operating/Version  Document:  Consists  of  two  major 
sections  -  Operating  Instructions  and  a  Version 
Description.  The  Operating  Instructions  tell  how  to 
execute  the  simulation  software.  The  Version  Description 
lists  all  software  elements,  hardware  elements,  and 
supporting  documentation  needed  for  simulation  execution 
and  maintenance  and  contains  a  record  of  all  software 
changes  subsequent  to  acceptance  testing. 

Figure  2.4-5  illustrates  the  development  and  flow  of  data  for  the 


design,  integration,  and  test  of  a  typical  computer  program.  The 
development  of  the  4  documents  is  shown  by  the  numbered  triangles 
/#\"  The  repeated  occurrence  of  /gX ,  /3\,  and  A  indicates  incremen¬ 

tal  development  of  the  Software  Design  Specification  (  / 2\  ) ,  Software 
Test  Document  <  A )  ,  and  Operating/Version  Document  (  /4\  ) . 


The  Software  Configuration  Management  Standards  provide  guide¬ 
lines  for  change  classification  and  control,  configuration  accounting, 
and  the  conduct  of  reviews  and  audits.  The  function  of  configuration 
management  will  provide  for  operating  and  maintaining  a  computer  pro¬ 
gram  library,  for  filing  and  processing  all  software  problem  reports 
(SPRs)  and  specification  change  notices  (SCNs) ,  and  coordination  of 
simulation  software  maintenance. 

These  standards  were  initially  presented  to  AFWAL/FIGD  in  the 
form  of  briefings/tutorials  to  familiarize  FIGD  personnel  with  the 
basic  concepts  and  procedures.  Following  the  briefings,  the  Manage¬ 
ment  Methodology  Standards  were  released  for  review  and  use. 

2. 4. 2. 2  Software  Management  Support  Tools 

The  second  phase  of  the  support  consisted  of  developing  two 
software  support  packages,  one  to  be  used  by  FIGD  in  controlling 
developed  software  and  the  other  to  tracking  FCDL  documents.  These 
software  programs  were  the  Computer  Program  Library  Catalog  (CPLC) 
Software  and  the  Documentation  Tracking  Program  (DTP)  software. 


The  objective  of  the  CPL  catalog  software  is  to  help  the  configu¬ 
ration  management  office  (CMO)  manager  of  FIGD  -aintain  inventories  of 
software  documents  and  products,  and  status  logs  on  change  requests 
(CRs)  and  specification  change  notices  (SCNs).  It  provides  a  means  to 
set  up,  change,  obtain  information,  or  delete  such  catalogs  as  needed. 

Three  different  catalog  files  formats  are  available  to  support 
CMO  activities:  inventory,  CR  status  log  and  SCN  status  log.  Each 

format  defines  the  organization  of  catalog  entries  into  data  fields 
and  provides  a  text  header  that  can  be  used  for  printouts  and  dis¬ 
plays.  Four  general  ideas  characterize  the  CPL  catalog  software: 

a)  It  provides  the  basis  for  creating  and  maintaining 
inventories  and  status  logs  pertaining  to  FIGD 
configuration  managed  software. 

b)  It  provides  means  of  printing  or  displaying  entries 


or  groups  of  entries  from  a  catalog  file. 

c)  It  may  be  used  by  clerical  personnel  assigned  to  the 
CMO  as  well  as  experienced  simulation  engineers  and 
programmers. 

d)  Access  to  inventories  and  status  logs  is  controlled 

by  means  of  passwords,  and  "read-only"  and  "read-write" 
privilege  levels. 

The  CPL  catalog  software  is  written  in  FORTRAN  77  and  operates  on 
the  SEL  32-77  computer  system  using  an  MPX  operating  system.  This 
software  is  currently  resident  on  the  AFWAL/FIGD  SEL32-77  computer 
system. 

Architecturally  the  CPL  catalog  software  provides  an  interface 
between  a  human  user  and  the  various  disk  files,  displays,  and 
printers  required  to  produce  or  use  various  CMO  catalogs.  The  inter¬ 
face  to  the  user  provides  the  user  with  instructions  and  commands 
necessary  to  create  and  update  a  catalog  file,  including: 

a.  Set-up  a  new  catalog  file  (i.e.,  inventory  or 
status  log) . 

b.  Access  an  entry  in  a  catalog  file. 

c.  Create  an  entry  in  a  catalog  file. 

d.  Modify  an  existing  entry  in  a  catalog  file. 

e.  Delete  an  entry  from  a  catalog  file. 

f.  Delete  a  catalog  file. 

g.  Print  or  display  data  from  a  catalog  file. 

h.  Copy  or  rename  a  catalog  file. 

i.  Print  instructions  on  how  to  use  this  software. 

Other  architectural  elements  are  also  included  to  provide  access 
to  internal  system  resources:  disk  files,  printing  equipment,  and 

displays.  The  complete  design  of  the  CPLC  software  is  documented  in 
the  Computer  Program  Library  Catalog  Software  Design  Specification, 
SCT  Document  #81-FIGD-005 ,  8  May  1981. 

Documentation  Tracking  Program  (DTP)  Software 

The  Systems  Operations  Group  of  AFWAL/FIGD  maintains  a  large. 
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hybrid  computer  facility.  This  facility  is  supported  by  a  large 
number  of  manuals  and  drawings  which  from  time  to  time  are  revised  to 
reflect  the  current  system  configuration.  Because  of  the  large  number 
of  documents,  many  of  which  have  been  distributed  to  various 
engineers,  a  need  exists  to  be  able  to  track  the  various  document 
revisions  already  distributed.  The  purpose  of  the  DTP  software  is  to 
provide  a  user-friendly  software  tool  that  will  aid  in  the  document 
tracking  task. 

The  DTP  Software  is  written  in  Fortran  77  +  and  operates  on  the 
SEL  32-77  computer  system  using  the  MPX  operating  system. 

The  program  is  used  to  inventory  AFWAL/FIGD  documentation. 
Inputs  to  the  inventory  file  entries  for  each  document  include  the 
following : 

a )  Document  Title 

b)  Publication  number 

c)  Edition  or  revision  number 

d)  Publication  date 

e)  Total  number  of  copies 

f)  Owner  and  number  of  copies 

g)  First  key  word 

h)  Second  key  word 

i)  Short  description 

The  program  makes  use  of  permanent  files  and  a  temporary  or  work¬ 
ing  file  -  used  to  hold  changes  and  additions.  If  changes  are  made  to 
a  file  the  DTP  software  will  copy  the  permanent  file  to  a  backup  per¬ 
manent  file.  The  program  then  writes  the  updated  working  file  to  the 
permanent  file. 

The  DTP  software  recognizes  six  commandes  used  to  aid  the  user  in 
maintaining  the  document  data.  They  are: 

HELP  -  User  instructions 

ADD  -  Adds  new  entries  to  the  file 

MODIFY  -  Modifies  an  entry 

DELETE  -  Deletes  a  specified  entry  from  the  file 

LIST  -  Displays  entries  from  a  catalog 


END 


Closes  all  files  and  returns  to  monitor 


The  add,  modify  and  delete  commands  are  password  protected  which 
means  the  user  must  enter  the  correct  password  to  use  these  commands. 

Four  SCT  documents  listed  below  were  generated  during  the 
development  of  this  software. 

-Documentation  Tracking  Program  Requirements, 

SCT  #5336-421-3,  7  July  1982 
-Documentation  Tracking  Program  Design  Document, 

SCT  #5336-421-5A,  30  Sept  1982 
-Documentation  Tracking  Program  Operating  Instructions, 

SCT  #5336-421-4,  30  Sept  1982 
-Documentation  Tracking  Program  Software  Test  Document, 

SCT  #5336-421-6,  30  Sept  1982 


2.4.3 


and  Recommendations 


AFWAL/FIGD  was  similar  in  ways  to  many  other  software  and  simula¬ 
tion  development  facilities.  Many  facilities  began  either  in  support 
of  single  projects  or  as  small  operations  staffed  by  a  select  group 
working  closely  together.  As  long  as  that  situation  persisted,  prob¬ 
lems  were  few.  As  the  number  of  separate  programs  using  the  facility 
increased,  so  did  the  size  and  complexity  of  the  facility.  Software 
of  many  different  types  was  developed.  Often,  software  documentation 
practices  were  inconsistent  or  absent  and  reuse  of  software  was  limit¬ 
ed.  With  the  advent  of  new,  more  capable  computers,  the  number  of 
users  of  a  facility  increased  but  there  was  not  a  corr  sponding 
increase  in  personnel  to  support  their  users.  Often  during  develop¬ 
ment,  as  deadlines  approached,  communications  broke  down,  coding  was 
the  highest  priority  task  and  documentation  was  an  afterthought. 
Although  the  finished  program  worked,  it  was  generally  not  up  to 
desired  standards  with  respect  to  readability,  maintainability,  and 
documentation . 

The  Software  Management  Methodology  which  SCT  developed  in  close 
concert  with  FIGD  was  aimed  at  eliminating  most  of  these  problems. 
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The  software  tools  developed  by  SCT  served  as  an  aid  in  implementing 
some  of  the  methodology.  However,  successful  implementation  of  a 
software  management  methodology  requires  a  commitment  on  the  part  of 
AFWAL/FIGD  top  management.  In  additon,  successful  implementation  of  a 
sofware  management  methodology  depends  on  its  acceptance  by  the  work 
force.  The  work  force  was  involved  in  its  design  as  an  initial  step, 
but  this  should  be  followed  up  by  a  consultation  and  tutorials.  Along 
these  lines,  the  establishment  of  a  core  of  experienced  individuals, 
well  indoctrinated  with  the  software  management  procedures,  is  essen¬ 
tial  in  providing  the  continuity  needed  for  successful  software 
implementation . 
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2.5  CONTROL  SYSTEMS  ANALYSIS  TASKS 


2.5.1  Ay ionic /Flight  Control  Reconfiguration 

2. 5. 1.1  Background  and  Goals 

The  purpose  of  this  study  was  to  examine  strategies  for  increas¬ 
ing  the  reliability  of  integrated  control  of  flight  systems  through 
reconfiguration,  particularly  the  concept  of  virtual  redundancy. 
Virtual  redundancy,  possible  in  highly  integrated  avionics/flight  con¬ 
trol  system  architectures,  involves  the  reconfiguring  of  system 
resources  so  as  to  create  redundancy  on  demand. 

The  virtual  redundancy  concept  is  illustrated  in  Figure  2.5-1. 
Before  any  processor  failures,  functions  may  be  assigned  to  processors 
as  indicated  in  the  upper  half  of  the  figure.  Upon  detection  of  a 
failure  of  one  of  the  processors  assigned  to  flight  control  (for  exam¬ 
ple)  ,  the  assignment  of  functions  may  be  redistributed  as  indicated  in 
the  lower  half  of  the  figure. 

Integrated  control  of  flight  implies  a  high  degree  of  dynamic 
coupling  between  avionics  and  flight  control.  Accordingly,  much  cur¬ 
rent  emphasis  is  being  placed  on  highly  integrated,  bus-oriented 
architectures  and  bus  topologies  which  exhibit  a  high  degree  of  con¬ 
nectivity  between  flight  control  and  certain  avionics  function  (e.g., 
Integrated  Fire/Flight  Control,  Integrated  Flight/Trajectory  Control, 
Terrain  Following/Terrain  Avoidance,  etc.). 

The  Reconfiguration  Study,  along  with  its  successor  experiments, 
attempted  to  exploit  this  high  degree  of  architecture  integration  and 
bus  connectivity  to  enhance  "coverage"  and  to  recover  lost  critical 
functions . 

"Coverage"  is  the  ability  to  detect,  isolate,  and  accommodate  or 
recover  from  failures.  If  coverage  is  sufficiently  effective,  systems 
with  reduced  hardware  redundancy  can  exhibit  abort  or  1 oss-of-control 
probabilities  comparable  to  higher  redundancy  systems  which  have 
lesser  coverage.  The  sensitivity  of  system  reliability  is  illustrated 
in  Figure  2.5-2  for  the  case  of  duplex  systems.  Typically,  coverage 
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is  provided  either  by  in-line  monitoring  (self-test,  etc.)  or 
cross-channel  monitoring  (voting)  techniques.  Of  course, 
cross-channel  voting  requires  at  least  three  valid  voters  for  fault 
isolation. 

A  unique  aspect  of  the  Reconfiguration  Study  is  examination  of 
virtual  redundancy  as  a  means  of  fault  isolation  for  cross-channel 
monitoring  when  only  two  signals  (for  example,  flight  control  proces¬ 
sor  computed  outputs)  are  present.  In  this  case,  fault  detection  is 
provided  by  a  persistent  miscompare  of  the  two  signals.  Fault 
isolation  if  not  successfully  performed  by  self-test  or  other  in-line 
techniques,  can  be  accomplished  (for  example)  by  causing  an  avionics 
processor  to  perform  a  "backup"  flight  control  solution  on  demand. 
This  third  signal  can  be  used  to  break  the  tie  concerning  which  flight 
control  processor  has  failed.  Recovery  can  be  effected  by  dynamically 
loading  a  spare  or  lease  essential  processor  with  flight  control  laws 
(again  for  this  example) .  The  replacement  processor  must  then  be  ini¬ 
tialized  so  as  to  ensure  its  smooth  and  rapid  inclusion  into  the 
redundancy  management  scheme. 

Recovery  of  lost  functions  as  described  above  is  of  particular 
importance  for  longer  mission  durations,  such  as  that  examplified  by 
the  Long-range  Combat  Aircraft. 

2. 5. 1.2  Study  Objectives  and  Scope 

The  major  objective  of  the  Reconfiguration  Study  was  to  provide, 
through  laboratory  demonstration,  a  general  assessment  of  the  feasi¬ 
bility  of  virtual  redundancy  and  system  reconfiguration  to  enhance 
coverage  and  recover  functions  lost  due  to  failures.  The  assessment 
was  oriented  towards  the  identification  of  architectural  design  issues 
and  the  resolution  of  these  issues  in  favor  of  (1)  ease  of  integration 
and  (2)  minimization  of  hardware,  which  are  primary  goals. 

The  scope  of  the  study  included: 

(1)  The  identification  and  analysis  of  design  issues; 

(2)  The  definition  of  a  candidate  architecture; 

(3)  The  implementation  of  the  architecture  in  a 


128 


laboratory  environment;  and 

(4)  The  collection  of  quantitative  data  regarding  the 
impact  of  reconfiguration  on  system  performance. 

Several  groundrules  were  adopted  in  the  approach  to  the  study  to 
limit  the  scope  realistically.  These  are  summarized  as  follows: 

(1)  Candidate  architectures  should  be  sufficiently  fault 
tolerant  that  a  single  processor  failure  does  not 
result  in  loss  of  mission  and  a  double  processor  failure 
does  not  result  in  loss  of  aircraft; 

(2)  Architectures  considered  should  be  bus-oriented  with 
high  connectivity  (flight  control  and  avionics  on  the 
same  bus ) ; 

(3)  Hardware  and  software  developed  in  the  DAIS  program 
should  be  used  for  laboratory  evaluation  where  possible, 
with  software  modification  as  necessary. 

2. 5. 1.3  Study  Approach 

The  approach  to  the  Reconfiguration  Study  was  issue  oriented, 
focusing  on  the  primary  issues  of  executive  interplay  between  proces¬ 
sors;  bus  loading/bus  control;  failure  detection,  isolation,  and 
recovery  (reconfiguration);  and  transient  effects.  As  mentioned  pre¬ 
viously,  the  study  attempted  to  utilize  the  DAIS  architecture  and 
executive  software  where  possible,  and  to  make  necessary  modifications 
where  practical  and  to  indicate  where  further  capability  of  the  DAIS 
approach  is  recommended. 

The  study  consisted  of  three  major  tasks: 

(1)  Conceptual  Analysis  and  Architecture  Selection; 

(2)  Development  of  a  Functional  Emulation  Tool;  and 

(3)  Laboratory  Evaluation. 

These  tasks  addressed  reconfiguration  issues  as  shown  in  Figure  2.5-3. 
The  purpose  of  the  conceptual  analysis  (Task  1)  was  to  perform  ana¬ 
lysis  necessary  to  focus  the  remainder  of  the  study  on  the  minimum 
complexity  architecture  that  is  capable  of  demonstrating  the  reconfi¬ 
guration  concept.  Task  2  developed  a  functional  emulation  of  the 
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candidate  architecture.  This  emulation  was  designed  to  have  the  capa¬ 
bility  to  study  issues  which  are  not  addressable  in  the  laboratory, 
either  because  of  hardware  limitations  or  because  modifications  to  the 
DAIS  executive  would  be  too  extensive  to  be  practical.  The  objective 
of  Task  3,  Laboratory  Evaluation,  was  to  demonstrate  the  reconfigura¬ 
tion  concept  in  a  laboratory  environment  and  to  collect  preliminary 
quantitative  data  on  the  (1)  impact  of  the  MIL-STD-1553  data  bus  on 
reconfiguration;  and  (2)  impact  of  the  reconfiguration  concept  on 
flight  control  and  safety  of  flight. 

2. 5. 1.4  Work  Accomplished 

The  work  accomplished  in  this  task  is  summarized  below: 

1)  Adapted  to  the  Flight  Engineering  Facility  a  multi¬ 
processor  System  Exec  from  the  DAIS  Exec  and  associated 
support  software. 

2)  Integrated  a  multiprocessor  avionics/flight  control 
architecture  with  real-time  simulation  capability. 

3)  Devised  a  workable  method  for  employing  virtual 
redundancy  and  reconfiguration  concepts  for  applications 
which  are  tolerant  of  reduced  update  rates  or  temporary 
suspension  of  output  command  (i.e.,  highly  stable  aircraft). 

4)  Established  ability  to  load  a  processor  over  1553  bus  and 
restart . 

5)  Established  ability  to  dynamically  initialize  a  processor. 

6)  Collected  preliminary  data  on  time-to-load  over  bus  and 
time-to-initalize/recover . 

7)  Developed  all-S/W  simulation  tool  for  analyzing  alternative 
algorithms  and  architectures. 

8)  Identified  limitations  of  and  problems  with  existing 
laboratory  hardware  and  software  (Exec)  which  were  GFE  for 
this  study. 
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2.  5.  1.5  Conclusions  and  Recommendations 

The  Reconfiguration  Study  has  come  a  long  way  towards  proving  the 
feasibility  of  the  concept  of  virtual  redundancy  and  reconfiguration 
as  a  means  of  increasing  the  reliability  of  integrated  avionics/flight 
control  systems.  Moreover,  the  laboratory  hardware  and  software  and 
support  software  (e.g.  Functional  Emulator)  are  now  in  place  to  pur¬ 
sue  experiments  which  will  thoroughly  explore  implementational 
considerations.  Recommendations  for  future  study  are  listed  below: 

(1)  Incorporate  software  modifications  to  the  down-loading 
function  to  allow  a  processor  other  than  itself  to 
initiate  the  down-load.  This  is  a  limitation  of  the 
existing  Exec/Bootstrap  Loader. 

(2)  Investigate  adding  the  capability  to  down-load 
"dynamically,"  i.e.,  without  having  to  halt  other 
processors.  In  the  current  laboratory  configurations, 
the  output  to  the  control  surface  is  essentially 
frozen  during  the  reconfiguration  process.  This  is 
necessary  because  the  current  System  Exec  cannot 
handle  reload/bootstrap  and  normal  operations 
simultaneously.  The  capability  to  allow  known  good 
processors  to  control  the  aircraft  during  recon¬ 
figuration  needs  to  be  added  in  future  experimentation. 

(3)  Add  a  third  processor  to  the  demonstration  configuration. 

This  will  enable  study  of  systems  of  dual  flight 
control  redundancy  and  will  also  enable  study  of  backup 
System  Exec. 

(4)  Streamline  the  System  Exec  to  make  it  more  practical  for 
flight  control  applications.  Currently,  emphasis 

on  the  Exec  design  is  towards  flexibility;  certain 
nonessential  functions  could  be  removed  to  greatly 
improve  efficiency  and  make  the  Exec  more  credible  in 
the  flight  control  application. 

(5)  Develop  techniques  for  monitoring  and  backup  of  the 
System  Exec  so  as  to  enhance  reliability  of  the  overall 
system.  Non-stationary  Master  (bus  control)  approaches 
should  be  examined. 
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(6)  Investigate  higher  levels  of  bus  redundancy  as  a  means 
to  increase  overall  system  reliability  and  to  improve 
data  throughout. 

2.5.2  Multivariable  Control  of  Wingsnape 
2. 5. 2.1  Background  and  Goals 

Demonstration  of  the  mission-adaptive  wing  (MAW)  technology,  also 
called  "smooth  variable  camber"  (SVC),  is  an  objective  of  the  Air 
Force's  Advanced  Fighter  Technology  Integration  Program.  The  perfor¬ 
mance,  control,  and  mission  effectiveness  benefits  for  an  aircraft 
with  a  smooth  variable  camber  wing  will  be  demonstrated  by  the 
AFTI/F-11 1  airplane.  The  design  objective  is  to  use  the  variable  wing 
camber  to  optimize  the  wing's  aerodynamic  efficiency  over  a  broader 
speed  range  and  to  provide  additional  control  devices.  Potential 
applications  for  the  variable  camber  wing  are  presented  in  Table 
2.5-1,  which  shows  the  control  function,  the  relative  control 
bandwidth  (i.e.,  how  fast  the  flaps  must  move)  and  considerations  for 
integration  of  the  camber  control  function  with  other  flight  control 
surfaces.  The  actual  mix  of  control  functions  is  dependent  on  the 
type  of  aircraft  and  its  mission  as  shown  in  Table  2.5-2. 

Acceptance  of  SVC  or  the  MAW  as  a  viable  aircraft  design  tech¬ 
nique  is  contingent  on  a  demonstrated  capability  to  establish  wing 
camber  which  is  fully  consistent  with  the  dynamics,  speed,  and  current 
flight  conditions.  Unless  this  is  an  automatic  capability,  the 
pilot's  workload  could  become  unacceptably  high.  He  would  need  to 
refer  to  wing  performance  charts,  select  the  most  appropriate  configu¬ 
ration,  and  then  appropriately  set  each  of  the  flap  deflections. 
While  this  may  be  an  acceptable  procedure  for  high-altitude,  steady- 
state  cruise,  it  cannot  be  considered  for  low  -  altitude  maneuvering 
flight  (e.g.,  terrain-following  and  avoidance). 

At  this  time,  demonstrated  techniques  to  set  wing  camber  automat¬ 
ically  do  not  exist  and  development  of  this  capability  must  be 
considered  a  priority  need.  Thus,  under  the  current  AFTI  F-lll  con- 
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Wing  Camber  Control  Requirements  pe-  Aircraft  Type 


tract,  two  approaches  to  automatically  control  wing  camber  are  being 
investigated;  namely,  "preprogrammed"  and  "sell  optimizing."  However, 
identified  weaknesses  of  each  of  these  control  modes  suggest  that 
research  and  development  in  this  area  continue  to  enable  SVC  benefit 
r  eal 1 zat ion . 

The  "preprogrammed"  camber  control  mode  is  expected  to  provide 
reasonably  rapid,  accurate  and  stable  wing  camber  settings.  However, 
implementation  of  this  mode  may  impose  rather  significant  hardware, 
test,  and  deployment  penalties.  For  an  aircraft  such  as  the  F-lll, 
this  mode  would  impose  significant  computer  memory  requirements  to 
store  symmetrical  control  surface  pair  setting  data  for  a  wide  range 
of  airspeeds  and  wing  sweep  positions  throughout  the  operating 
envelope  in  redundant  computer  memories.  Also,  performance  and  bene¬ 
fits  of  this  mode  would  be  directly  related  to  the  extent  and  accuracy 
of  the  aerodynamic  performance  data  of  the  wing.  This  condition  has 
the  undesirable  implication  that,  in  a  given  mission  aircraft  design, 
extensive  wind  tunnel  and  flight  testing  would  be  required  to  estab¬ 
lish  an  adequate  control  model.  Accuracy  of  these  data  would  be 
subject  to  stores  combinations  and  any  subsequent  changes  in  the  wing 
may  require  retesting,  control  system  reprogramming,  and  safety  recer- 
1 1 f i cat  ion . 

An  automatic,  "self-optimizing"  camber  control  technique  may 
conceivably  overcome  these  concerns.  Several  adaptive  techniques  have 
seen  suggested  and  the  one  selected  for  tne  AFTI  F-lll  demonstration 
employs  longitudinal  velocity  changes  as  the  feedback  parameter. 
Incremental  airspeed  changes  will  be  used  to  assess,  in  flight,  wheth¬ 
er  HAW  control  surface  position  changes  improve  wing  efficiency. 
Although  this  mode  may  overcome  some  disadvantages  of  the  prepro¬ 
grammed  camber  setting  technique,  its  weaknesses  are  also  significant. 
For  example,  dynamic  errors  in  an  altitude  hold  loop,  thrust  varia¬ 
tions  or  airmans  instabilities,  such  as  turbulence,  may  be  interpreted 
by  the  flight  control  computer  to  result  from  changes  in  camber  set¬ 
tings.  Similarly,  camber  adjustments  may  couple  into  and  adversely 
affect  other  cruise  mode  performance,  e.g.,  altitude  hold  or  Mach 
hold.  Possibly,  by  interating  the  camber  cnanges  at  a  sufficiently 
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slow  rate,  mode  cross-coupl i ng  effects  would  be  reduced  to  an  accept¬ 
able  minimum  at  the  expense  of  dynamic  response. 

Optimum  camber  selection  is  a  multivariable  control  problem  and 
may  require  use  of  modern  control  techniques  for  satisfactory  perfor¬ 
mance.  Modern  control  design  techniques  are  well  -  suited  for  the 
development  of  an  active  MAW  control  system  for  two  reasons.  First, 
multivariable  synthesis  techniques  offer  a  systematic  method  for 
optimizing  control  law  structures  for  multiple  control  requirements 
(e.g.,  drag  minimization  and  maneuver  load  alleviation  for  maneuvering 
flight)  where  a  number  of  sensor  signals  and  control  surfaces  are 
available  for  the  control  law.  Second,  estimation  techniques  would  be 
used  to  generate  the  required  signals  for  the  multivariable  control 
law.  For  example,  estimation  filters  could  be  used  to  define  angle -of- 
attack,  lift  coefficient,  drag  coefficient,  or  some  other  parameter 
which  represents  a  flight  performance  figure  of  merit.  The  design 
consideration  for  the  estimation  filters  is  that  they  must  be  capable 
of  real-time  implementation  (which  requires  minimizing  the  software 
computational  burden)  and  that  their  performance  must  not  be  degraded 
by  maneuvering  flight  or  by  sensor  system  noise. 

Prior  to  the  initiation  of  the  program  described  in  this  report, 
the  available  technical  data  base  was  inadequate  to  support  a  mul¬ 
tivariable  control  design  implementation  within  the  AFTI/F-111  MAW 
development  program  schedule.  In  response  to  this  deficiency,  the 
Flight  Control  Division  of  the  Flight  Dynamics  Laboratory  formulated 
in  exploratory  study  to  develop  the  modern  control  design  technology 
lor  aircraft  applications.  Objectives  of  this  technology  development 
study  are  listed  as  follows: 

•  evaluate  the  application  of  modern  control  design 
techniques  to  the  synthesis  of  complex  aircraft 
control  laws. 

•  Define  multifunctional/multivariable  control  law 
structures  which  are  adapted  to  advanced  aircraft 
mission  requirements. 

•  Assess  the  design  impact  of  multivariable/multi- 
f  unc-tional  control  systems. 
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2. 5. 2. 2  Work  Accomplished 


A  summary  of  the  work  accomplished  in  this  task  is  given  below: 


(1)  Developed  the  design  objectives  and  requirements 
for  the  flight  control  system  of  an  aircraft  that 
integrates  smooth  wing  camber  control  with 
conventional  aircraft  controls. 

(2)  Developed  a  conceptual  design  of  a  multivariable/ 
multimode  flight  control  system. 

(3)  Developed  an  overview  of  multivariable  design 
techniques  and  a  detailed  description  of  linear 
quadratic  synthesis  methods. 

(4)  Prepared  a  technology  assessment  of  the  proposed 
flight  control  system  and  recommendations  for  a 
research  and  development  program  that  addresses 
these  issues. 


2 . 5 . 2 . 3 


Conclusions 


The  study  investigated  the  integrated  design  of  a 
multivariable-multifunctional  control  system  based  on  the  application 
of  modern  control  design  techniques.  An  example  of  the  need  for  such 
integrated  design  methods  is  an  aircraft  that  combines  wing  shape  con¬ 
trol  (which  is  mechanized  to  continuously  control  the  leading  and 
trailing  edge  deflections)  with  conventional  aircraft  controls  (i.e., 
stabilon,  throttle,  rudder)  for  enhanced  aircraft  performance  and  han¬ 
dling  qualities.  This  type  of  control  system  requires  integration  of 
aircraft  stabilization,  configuration  management  and  structural  load 
control  functions  that  can  benefit  the  operational  performance  of  the 
aircraft  for  takeoff,  climb,  cruise,  combat,  and  landings  modes  of 
flight.  The  actual  mix  between  control  functional  requirements  and 
modes  of  flight  varies  with  aircraft  type  (i.e.,  penetration  bomber, 
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large  transport,  cruise  missile  carrier  or  fighter). 

Modern  control  design  techniques  are  well  suited  for  the  develop¬ 
ment  of  complex  control  systems  such  as  the  MAW,  for  two  reasons. 
First,  multivariable  synthesis  techniques  offer  a  systematic  method 
for  optimizing  control  law  structures  for  multiple  control  require¬ 
ments  (e.g.,  drag  minimization,  lateral  control,  and  maneuver  load 
alleviation  for  maneuvering  flight)  where  a  number  of  sensor  signals 
and  control  surfaces  are  available  for  the  control  law.  Second,  esti¬ 
mation  techniques  would  be  used  to  generate  flight  condition  and 
camber  corrections  for  optimizing  the  aircraft  performance  and  the 
required  signals  for  the  multivariable  control  law.  For  example, 
estimation  filters  could  be  used  to  define  wing  tip  deflection  for  a 
maneuver  load  control  law. 

Specific  design  features  of  the  designed  MAW  multivariable  multi¬ 
mode  flight  control  system  are  summarized  as  follows: 

•  Single  Control  Structure 

-Commanded  »  Q»  a»Y  or  8*  V,  h,  P 

are  kinematically  consistent 
-Mode  selection  is  based  on  mode  logic  for 
n ,  6 ,  y,  V.  and  h 

•  Forward  path  control  generator  for  all  controls 
(SI.  6V  S„  ) 

-Control  commands  are  aerodynamically 
consistent  with  flight  variable  commands 
-Integral  error  regulator  terms  are  only 
needed  for  modeling  errors,  not  for  trim 

•  Multi-Command  Control  select 

-All  commands  pass  to  servo  when  servo  isn't 
saturated 

-Commands  are  dynamically  limited  on  a 
prioritized  basis  when  servo  is  saturated 


A  comparison  of  control  system  design  philosophies  for 
multivariable-multimode  MAW  with  the  AFTI-16 ,  AFTI-111  and  the  F-18  is 


presented  in  Table  2. 5^3. 

The  described  control  structure  for  a  MAW  optimal  performance 
seeking  flight  control  system  offers  great  potential  for  making 
improvements  in  the  control  of  an  aircraft  for  performance,  handling 
qualities,  and  structural  load  reduction.  It  provides  a  solution  to 
the  design  goals  formulated  at  the  outset  of  this  discussion.  By  vir¬ 
tue  of  this  being  a  new  and  different  aircraft  flight  control  system 
structure,  there  are  a  number  of  technology/design  issues  that  must  be 
resolved  in  order  to  qualify  the  benefits  of  this  approach.  These  are 
listed  below. 

(1)  How  accurate  must  the  aerodynamic  models  which  are 
used  for  the  optimal  path  generator  and  the 
maneuver  command  generator  be?  The  issues  are 
modeling  complexity,  accuracy  of  the  wind  tunnel 
predictions,  and  the  impact  of  the  regulator  and 
the  on-line  performance  estimator  for  compensating 
for  potential  modeling  errors. 

(2)  How  identifiable  are  the  flap  and  flight  condition 
corrections  for  the  on-line  performance 
optmization?  The  issues  are  quality  of  the  fuel 
flow  measurements  for  multiple  engines,  a  requirement 
for  modeling  engine  and  aircraft  transients,  and 

the  magnitude  of  flight  variable  perturbations  which 
are  required  to  generate  statistically  significant 
identification  results.  In  addition,  would  these 
perturbations  be  acceptable  to  the  pilot? 

(3)  How  accurate  is  the  wing  root  bending  estimation 
algorithm  and  what  is  its  performance  in  maneuvering 
f 1 ight? 

(4)  What  are  the  design  problems  associated  with 
implementing  the  multivariable  optimal  regulator 
for  the  aircraft  mission?  The  issues  are 
regulator  design  items  such  as  selection  of 
weighting  factors,  cost  function  implementation, 
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the  impact  of  modeling  uncertainty,  methods  for 
reducing  the  complexity  of  the  gain  matrix,  and 
potential  requirements  for  implementing 
nonlinearities. 

2. 5. 2. 4  Recommendations 

All  of  the  technical/design  issues  just  described  can  be 
addressed  with  a  study  based  on  a  limited  scope  (non-piloted  and 
piloted)  simulation.  The  simulation  could  be  based  on  the  AFTI/F-111 
aircraft  with  the  nonlinear  aerodynamic  model  defined  for  one  wing 
sweep  position,  a  range  in  Mach  number  of  . 2  <  M  <  .9,  and  be  func¬ 
tionally  dependent  on  angle-of -attack  and  altitude.  This  range  in 
Mach  number  would  allow  investigation  of  landing  approach,  maximum 
endurance  and  maximum  range  flight  test  conditions.  The  engine  model 
requirements  include  accurate  representation  of  fuel  flow,  transient 
response,  and  performance  dependence  on  ambient  atmospheric  condi¬ 
tions.  A  peripheral  model  (i.e.,  one  that  does  not  contribute  to  the 
dynamic  degrees  of  freedom)  of  wing  root  bending  is  also  required.  To 
aid  the  design  of  the  regulator,  the  nonlinear  simulation  must  have 
the  capability  to  generate  a  linear  state  model  at  a  trimmed  operating 
point . 

An  outline  for  a  study  plan  based  on  the  MAW  simulation  and 
structured  to  provide  answers  to  the  posed  technology/design  issues  is 
shown  in  Figure  2.5-4. 


2. 5. 3.1  Background  and  Goals 


The  F IREBOLT  is  a  hybrid  rocket-powered,  high-altitude,  superson¬ 
ic,  recoverable  target.  The  FIREBOLT  is  air-launched  from  an  F-4 
aircraft  and  is  capable  of  climbing  from  launch  altitude  to  any  preset 
altitude  up  to  10,000  feet  with  speeds  from  approximately  Mach  0.9  to 
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Mach  4.0.  The  FIREBOLT  is  designed  to  respond  to  ground  initiation 
and  automatic  initiation  of  preprogrammed  maneuvers.  The  vehicle  con¬ 
trol  system  is  also  designed  to  maintain  ±.l  Mach  number  variation  of 
a  preset  speed  during  these  maneuvers.  The  FIREBOLT  will  perform  high 
"g"  (1.1  to  5)  lateral  turns,  high  "g"  (±5.0)  vertical  maneuvers, 

S-turns,  Mach  number  increases/decreases,  and  +5000  foot  altitude 
maneuvers.  Because  these  maneuvers  are  typical  evasive  enemy  tactics, 
they  provide  the  user  a  more  realistic  target  to  train  air  crews  or 
evaluate  advanced  missile  weapon  systems  such  as  the  AMRAAM. 

The  purpose  of  this  task  was  to  develop  a  simulation  which  pro¬ 
vides  the  EgLin  Air  Force  Base  Armament  Division  an  in-house,  quick- 
reaction  capability  to  evaluate  the  FIREBOLT  performance  and  stability, 
independent  of  the  prime  FIREBOLT  contractor's  assessments , and  provide 
a  tool  for  the  FIREBOLT  flight  test  program. 

The  main  objectives  of  this  project  were  to: 
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(1)  Develop,  update,  maintain  and  validate  the  six-degrees- 
of-freedom  (6D0F)  digital  simulation.  This  included 
all  design  changes  to  the  FIREBOLT  vehicle  made  by 

TRA  or  the  Air  Force  and  included  model  updates  based  on 
post-flight  test  analysis.  All  updates  were  documented 
and  provided  to  the  Air  Force.  Validation  of  the 
simulation  was  accomplished  by  matching  simulation 
performance  characteristics  to  flight  test  results.  The 
6 DOF  simulation  was  written  in  FORTRAN  IV  and 
subsequently  modified  to  FORTRAN  V,  and  is  compatible 
with  the  CDC  6600  at  Eglin  Air  Force  Base. 

(2)  Provide  an  independent  assessment  of  the  FIREBOLT  flight 
control  system  design,  including  design  changes  and 
modifications.  Also  provide  written  and  oral  comments  on 
FIREBOLT  contract  data  items  in  the  areas  of: 

•  Flight  control  system 

•  Aerodynamics 

•  Test  plans,  reports,  and  analysis. 

(3)  Provide  pre-  and  post-flight  test  analyses  on  each  flight 
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test  vehicle  to  include,  but  not  be  limited  to,  flight 
performance,  profile,  sensitivity  analysis,  diagnostic 
analysis  of  problems  and  recommendations. 

(4)  Provide  operational  instructions  to  Air  Force  personnel 
in  the  use  of  the  6  DOF  simulation. 


2. 5. 3. 2  Work  Accomplished 


All  the  objectives  of  the  task  were  completed.  An  overview  of 
the  digital  simulation  is  presented  below. 

The  current  FIREBOLT  target  model  simulates  the  motion  of  a  rigid 
body  through  the  atmosphere  in  three-dimensional  space  with  respect  to 
a  flat  non-rotating  earth. 

The  model  is  based  on  physical  modularity  in  which  parts  of  the 
program  called  modules  functionally  represent  subsystems  of  the  mis¬ 
sile  or  its  external  environment.  The  order  of  processing  the  modules 
is  shown  in  Figure  2.5  5,  which  is  generally  clockwise  beginning  with 
the  airframe  and  external  environmental  modules,  proceeding  through 
the  sensor  modules,  and  finally  to  the  steering  and  control  modules. 
There  are  five  functional  groups  of  modules  in  the  program  identified 
by  the  letter  G  (geophysical),  S  (sensor),  C  (computers),  A  (air¬ 
frame)  ,  and  D  (dynamics) .  The  names  and  functions  of  the  modules  are 
as  follows. 

FIREBOLT  Simulation  Modules  and  their  Fuacti,Q..ns 

G2:  Wind  and  Gust  Module:  Computes  wind  components,  air  density, 

and  speed  of  sound  from  measured 
atmospheric  conditions.  Used  to 
simulate  a  specific  test  flight. 

G3 :  Air  Data  Module:  Computes  wind  components  and  atmos¬ 

pheric  data  from  a  standard  atmosphere 
model . 


G3 :  Air  Data  Module: 


G5:  Coordinate  Conversion 
Module : 


Computes  Euler  angles  and  trans- 


Figure  2.5-5  FIREBOLT  Major  Subsystems  for  6  DOF  Simulation 
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formations  between  the  earth-fixed 
and  the  body-fixed  coordinate 
systems.  Also  computes  angle 
of  attack  and  sideslip. 

Cl:  Autopilot  Module:  Includes  navigation  functions 

and  vehicle  stabilization 
computations  using  sensor  data 
and  input  parameters.  Outputs 
of  this  module  are  the  control 
deflection  commands. 

C4:  Actuator  Module:  Computes  the  dynamics  for 

the  actuators'  control  surfaces. 

A1 :  Aerodynamic  Coefficients:  Interpolates  for  aerodynamic 

coefficients  as  a  function 
of  Mach  number,  angles  of 
attack,  and  control  defelctions. 
Computes  the  total  forces  and  moment 
of  aerodynamic  coefficients. 

A2:  Aero  Force  and  Moment  Computes  the  aerodynamic  forces 

Module:  and  moments  acting  on  the  vehicle. 

A3:  Propulsion  Module/Mass  Computes  control  signals  to  the 
Properties:  propulsion  unit.  Contains 

a  model  of  the  propulsion 
system  and  the  mass  properties 
variations  due  to  fuel  burned. 

Dl:  Translational  Dynamics:  Computes  vehicle  accelerations 

due  to  aerodynamic  and 
propulsion  forces.  Transforms 
acceleration  to  the  earth-fixed 


coordinate  system,  adds 
gravitation,  and  integrates 
to  compute  velocity  and  position. 

D2 :  Rotational  Dynamics  Evaluates  total  moment  (including 

Module:  thrust  misalignment)  acting 

on  the  vehicle  and  computes 
the  rotational  dynamics  of  the 
airframe.  Also  updates  direction 
cosines  from  updated  body  rates. 

A  brief  description  of  each  module  is  given  in  Table  2.5-4.  The 
modules  are  interconnected  by  COMMON  storage  location  called  C(3510). 
The  module  interconnection  diagram  is  shown  in  Figure  2.5-6.  This 
diagram  shows  the  principle  variables  going  from  one  module  to  anoth¬ 
er  . 

This  simulation  was  developed  on  the  Eglin  CDC  CYBER  computing 
system.  Several  unique  capabilites  have  been  built  into  the  FIREBOLT 
software.  It  has  the  ability  to  recall  every  subscripted  numerical 
value  used  in  the  program  during  the  first  few  integration  steps  for 
debugging  purposes.  It  can  produce  4020  film  plots  of  fifteen  vari¬ 
ables  versus  time  for  each  executed  trajectory,  or  plot  two  variables 
against  each  other  with  the  remaining  thirteen  variables  versus  time. 
It  also  has  the  ability  to  display  the  variables  and  their  numerical 
location  in  common  storage  in  alphabetical  and  numerical  order.  This 
unique  feature  of  the  model  is  a  powerful  debug  device  which  reveals 
available  storage  locations  for  new  variables,  identifies  those 
presently  being  used,  and  flags  variables  that  occupy  the  same  memory 
location  but  have  different  variable  names  and  the  percentage  of 
unused  common  storage.  Finally,  it  can  produce  numerical  results  for 
each  integration  step  (or  larger  time  increment)  for  sixty  output  var¬ 
iables  per  computer  run.  Any  variable  selected  should  be  in  the 
C (3510)  array. 
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Table  2.5-4 


Definitions  of  Frequently  Used  Variables 


Varlables_ox_Constants^ Associated  with  Modules 


Module 

Variable 

^  Units 

Def init ion 

G2 

WTX’  WTY'  WTZ 

ft /sec 

Components  of  wind,  including 
gusts 

G3 

qd 

lb/ft2 

Dynamic  pressure  (l/2p  V  ) 

M 

(non-d im) 

3 

Mach  number 

a, 6 

degrees 

Angles  of  attack  and  sideslip 

VAT 

f  c / sec 

Missile  velocity  with  respect 
to  air 

G5 

0 , 6 ,4> 

degrees 

Euler  angles,  yaw,  pitch,  roll 
from  tangent  plane  to  missile 
body  axes 

R 

s 

feet 

Slant  range  from  missile  to 
origin  of  tangent  plane 

V 

f t/sec 

Magnitude  of  missile  velocity 

Cl 

6CC’  6ac 

degrees 

Control  surface  deflection 
commands  from  navigation  and 
stabilization  autopilot  loop 

C4 

V  6a 

degrees 

Control  surface  deflections 
causing  moments  about  missile 
axes  (e.g.,  aileron,  canards) 

A1 

Wcn 

cp ’cm’c 
x.  m  n 

(non-d  ini) 

(non-dim) 

Aerodynamic  coefficients, 
body  axes 

A2 

S 

Reference  area 

c 

Reference  length 

FX’FVFZ 

ft-lb 

Components  of  aerodynamic 
force  along  wind  (AA)  or 
body  (BA)  axes 

i.m.n 

f  t-lb 

Components  of  aerodynamic 
moment  along  body  axes 

A3 

WTZ 

lb 

Components  of  thrust  force 
along  wind  (AA)  or  body  (BA) 
axes 

ft-lb 

Components  of  thrust  moment 
along  wind  (AA)  or  body  (BA) 
axes 

l/io 


A«JT\>PILOT 


C5 


\u 

'  coordinate  j 

CONVERSION  1 

figure  2.5-6  Module  Interconnection  Diagram  for  FOREBOLT  Simulation 


2.6  CONTROL/DISPLAY  DEVELOPMENT  SUPPORT 


Systems  Control  Technology,  Inc.,  is  supporting  the  Crew  Systems 
Integration  Branch  of  the  Air  Force  Wright  Aeronautics  Laboratories 
(AFWAL/FIGR)  in  the  development  of  control  display  technology.  The 
digital  synthesis  simulator  ( DIG  IS YN )  is  used  to  investigate  the 
impact  of  digital  avionics  information  on  pil ot/ai rcraf t  performance 
and  effectiveness. 

DIGISYN  consists  of  a  fixed-base  A- 7  cockpit,  a  test  operator's 
console  (TOC) ,  and  a  computer  system.  The  fixed-base  cockpit  is  out¬ 
fitted  with  advanced  controls  and  displays  as  follows:  1)  head-up 
display  (HUD) ,  2)  veritcal  situation  display  (VSD) ,  3)  horizontal 
situation  display  (USD),  4)  multi-function  keyboard  (MFK ) ,  5) 
multi-purpose  display  (MPD ) ,  6)  master  mode  panel  (MMP) ,  and  7)  master 
function  select  (MFS )  panel.  The  HUD,  VSD,  HSD ,  and  MPD  are  displayed 
on  Cathode  Ray  Tube  (CRT)  devices.  The  MFK  is  implemented  by  using 
either  a  CRT  display  with  peripheral  push  button  switches  or  by  using 
an  array  of  projection  switches.  The  MMP  and  MFS  are  arrays  of 
back-lighted  pushbutton  switches.  The  cockpit  also  includes  tradi¬ 
tional  controls  and  displays  as  follows:  1)  McFadden  three-axis 
control  loader,  2)  throttle,  3)  map  cursor  control,  and  4) 
electro-mechanical  analog  instruments. 

The  TOC  provides  real-time  test  monitoring  and  control  for  a  team 
of  investigators.  Each  cockpit  display  is  repeated  on  the  TOC  for 
monitoring,  and  an  array  of  push-button  control  switches  is  provided 
for  test  sequencing. 

The  computer  system  provides  a  real-time  simulation  of  the  A-7 
airframe,  generates  and  drives  the  cockpit  displays,  scores  pilot  per¬ 
formance  during  threat,  pop-up  and  MFK  tasks,  and  records  data  for 
off-line  statistical  analyses.  The  central  computer  is  a  PDP-11/50 
with  1 24K  words  of  memory.  The  following  peripherals  complement  the 
LDP-11/50:  1)  color  as  well  as  black  and  white  RAMTEK  GX-100A  graphic 
generators,  2)  dual  1.2M  word  disk  cartridge  drives,  3)  9-track  mag¬ 
netic  tape  drive,  4)  general  purpose  control  and  display  (GPCD) 
system,  5)  CRT  console  terminal,  6)  card  reader,  7)  electrostatic 
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printer,  8)  digital  input/output  (I/O)  channel,  and  9)  analog  I/O 
channel.  A  pictorial  diagram  of  the  DIGISYN  is  presented  in  Figure 
2.6-1. 

The  DIGISYN  facility  is  being  used  for  investigation  of  cockpit 
displays,  display  formats,  and  cockpit  communication  methods.  The 
support  tasks  included:  (1)  2-D  Display  Software  Support,  (2)  Color 
Terrain  Display  System,  (3)  Speech  Applications  Experimental  Support, 
(4)  Flat  Panel  Display,  (5)  Pictorial  Emergency  Procedures/Speech 
Interaction,  and  (6)  Microprocessor  Application  of  Graphics  and  Inter¬ 
face  Communication. 


2.6.1  2-D 


A  two-dimensional  microwave  landing  system  display  format  was 
developed  by  AFWAL/F IGR  to  examine  the  feasibility  of  integrating 
attitude,  lateral  performance,  predicted  lateral  performance  and  situ¬ 
ation  information  on  a  single  display  surface.  The  profile  was  a 
single  scale  graphic  view  of  the  path  to  be  flown  (see  Figure 
2. 6. 1-1).  The  entire  profile  rotated  with  aircraft  heading  changes  so 
that  current  heading  was  always  at  the  top  of  the  display.  In  this 
way,  drift  was  always  shown  the  same  as  it  would  be  seen  in  a  real 
world,  heads  up  manner.  The  flight  path  moved  toward  the  bottom  of 
the  display  surface  and  to  the  center  of  the  aircraft  symbol  when  on 
course,  at  a  rate  scaled  to  groundspeed.  The  need  for  this  kind  of 
display  configuration  became  apparent  when  pilots  experienced  problems 
with  position  orientation  and  control  on  complex  MLS  approach  trajec¬ 
tories.  Systems  Control  Technology  was  responsible  for  developing  a 
navigation  math  model  and  navigation-steering  software  required  to 
present  the  format  in  real-time,  interface  software  with  existing 
DIGISYN  software,  and  engineering  analysis  support  in  the  modification 
of  the  existing  aircraft  model  software  to  enable  simulation  experi¬ 
ments  to  take  place. 


MLS  Sof tware  -  The  MLS  software  was  written  to  compute  a 
predicted  aircraft  position  at  selected  times  in  the  future.  With  the 
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addition  of  a  desired  ground  track  display,  the  pilot  was  able  to  see 
ground  track  errors  and  judge  for  himself  any  corrective  measures  to 
be  made  to  the  aircraft  flight  path.  Curved  track  legs  between  way- 
points  were  supported  in  order  to  accommodate  realistic  landing 
patterns.  Software  was  also  written  to  generate  a  pitch  command  to 
the  pilot  to  allow  for  corrections  in  altitude  error  relative  to  a 
pre-defined  set  of  waypoints.  The  most  salient  features  of  the  MLS 
software  are  summarized  as  follows. 

A.  Path  Prediction:  The  MLS  software  relieved  airframe 
velocity  information  and  generated  predicted  ground 
positions  at  times  5,  10,  and  15  seconds  relative  to 
current  position  and  time. 

B.  Curved  Track  Legs:  The  path  between  waypoints,  formerly 
a  mandatory  straight  line,  allowed  for  a  curved  path. 

The  only  limitation  on  the  curve  was  that  it's  radius 
had  to  be  fixed. 

C.  Altitude  Tracking:  MLS  commands  provided  climb  and  dive 
rate  information  to  the  pilot  to  allow  easy  tracking  of 
a  given  reference  altitude.  Rate  damping  was  included 
to  allow  smooth  approaches  to  the  command  altitude. 

D.  Glide  Slope  Indicator:  At  the  beginning  of  the  seventh 
track  leg,  a  glide  slope  error  indicator  was  activated. 

Unlike  a  conventional  conical  patterned  GSI  error 
envelope,  the  MLS  software  generated  an  error  corridor 
such  that  a  given  GSI  deflection  always  translated  to 

a  constant  error. 

E.  Fastest  Possible  Run-Time  Execution:  All  of  the  complex 
calculations  were  performed  in  the  initial  condition 
mode,  leaving  only  labeled  variables  and  simple  equations 
to  be  performed  in  the  real-time  run  mode. 
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F.  In  order  to  simplify  many  calculations,  all  references  to 
latitude  and  longitude  were  converted  to  feet.  The 
beginning  point  of  the  mission  was  defined  as  (0,0). 

DIGISYN  Interface  Software  -  In  order  for  the  MLS  software  to 
operate,  data  from  the  airframe  model  had  to  be  sampled  in  real  time. 
A  memory  partition  named  SYSCOM  (System  Common)  was  created  to  accom¬ 
plish  this  needed  interface.  Three  different  areas  of  SYSCOM  (VSD2D, 
BLOCKS  and  SWITCH)  were  created.  All  communication  between  the  MLS 
software  and  airframe  software  was  accomplished  by  passing  parameters 
through  the  BLOCKS  area.  All  communication  between  the  MLS  software 
and  VSD  display  software  was  accomplished  by  passing  parameters 
through  both  the  VSD2D  and  BLOCKS  areas.  All  communication  between 
the  MLS  software  and  switch  processing  software  was  accomplished  by 
passing  data  through  the  SWITCH  area. 

Two  modules  of  the  aircraft  model  were  modified  for  the  MLS  simu¬ 
lation  experiment.  Subroutine  EARTH F ,  a  routine  which  integrates  the 
ground  position  of  the  aircraft  from  the  ground  velocities,  was  modi¬ 
fied  to  calculate  all  distances  and  positions  in  feet  instead  of 
radians.  This  allowed  the  MLS  software  to  use  feet  as  the  unit  of 
measure,  saving  computational  time.  The  AERO/module  which  computes 
pitch,  roll,  yaw,  lift  and  drag  components  from  a  linear  aerodynamic 
model  was  modified  to  include  a  ramp  function  to  introduce  drag  and 
lift  from  flaps  and  landing  gear.  This  modification  produced  a  more 
gradual  and  realistic  effect  than  the  effect  produced  by  the  original 
step  function  input.  The  ramp  function  was  implemented  with  a  period 
of  2.5  seconds. 

The  MLS  software  is  documented  in  the  Computer  Program  Product 
Specification  for  the  Microwave  Landing  System  (MLS)  software,  Simula¬ 
tion  Technology  Document  Number  STI-80-OPR-084 ,  29  December  1980. 

2.6.2  Col. ox  Terrain  Display  System 


In  order  to  assist  the  fighter  pilot  of  the  future  in  performing 


a  mission,  AFWAL/FIGR  personnel  examined  the  feasibility  of  using  a 
color  CRT  to  display  a  synthetic  terrain  format  to  the  pilot.  This 
format  provides  a  computer  generated  version  of  the  real  world  and  can 
be  generated  by  digitizing  terrain  and  cultural  features  and  storing 
them  in  an  on-board  computer.  The  data  can  then  be  correlated  with 
the  aircraft's  inertial  navigation  system  during  flight  and  presented 
to  the  pilot  on  a  head-down  E-0  display  device. 

The  feasibility  of  using  computer  image  generation  techniques  to 
display  terrain  and  cultural  features  was  demonstrated  under  a  previ¬ 
ous  Synthetic  Terrain  effort.  The  DIGISYN  was  used  as  the  test-bed 
for  performing  the  effort.  The  effort  yielded  a  Synthetic  Terrain 
Display  Format  that  could  be  updated  in  approximately  3-5  seconds,  not 
close  to  a  real-time  update.  The  slow  update  rate  appeared  to  be 
caused  by  the  DIGISYN  PDP-11/50  computer  system  and  the  RAMTEK  graph¬ 
ics  generators. 

The  Synthetic  Terrain  Expanded  Capability  Analysis  was  concerned 
with  definitizing  the  reasons  for  the  non-real-time  update  of  the  ter¬ 
rain  format  and  specifying  how  they  could  be  overcome.  This  involved 
not  only  examining  the  DIGISYN  hardware  and  software,  but  examining 
both  computer  and  graphics  hardware  that  could  be  added  to  generate  a 
real-time  synthetic  terrain  display  format,  and  that  could  be  expanded 
to  generate  other  complex  display  formats.  The  solutions  examined 
included  modifying  the  algorithm  for  the  terrain  calculation  and  dis¬ 
play,  as  well  as  the  connection  of  additional  computer  and  graphics 
hardware.  In  order  to  meet  the  objectives  of  this  effort,  a  number  of 
specific  tasks  were  undertaken.  They  are  described  in  the  following 
sections . 

Requirements  Definition  -  In  defining  the  requirements  of  the 
display  system,  certain  limits  were  placed  on  both  the  scenario  and 
aircraft  performance.  The  proposed  scenario  consisted  of  a 
straight-in  leg  to  the  target,  a  pop-up  maneuver,  a  45  degree  dive  to 
the  target,  weapon  delivery,  and  then  continuation  onto  another 
"straight  and  level"  leg  of  the  mission.  Aircraft  performance  limits 
were  placed  at  100-5000  feet  of  altitude,  600  knots  calibrated 


airspeed,  +  45  degrees  of  flight  path  angle,  ±  60  degrees  of  bank  and 
+  26  degrees  horizontal  134  +  13.5  degrees  vertical  field  of  view. 
With  these  bounds,  a  10  minute  demonstration  covering  100  miles  of 
terrain  data  base  was  defined.  Terrain  features  such  as  mountains  and 
trees  and  cultural  features  such  as  railroad  tracks,  bridges,  roads, 
rivers,  lakes,  city  outlines,  airports,  warehouses,  trains,  tall 
buildings  and  transmission  lines  were  identified  as  features  that  must 


be  displayed  and  easily  recognizable. 

Requirements  were  also  defined  for  the  display  itself.  It  was 
determined  that  a  5  or  7  inch  diagonal  color  display  with  a  512  x  512 
resolution  and  fine  pitch  (spacing  between  adjacent  color  triads)  in 
the  case  of  a  3-gun  tube  of  no  more  than  0.31mm  was  required  for  this 
task.  The  complexity  of  the  format  necessitated  an  update  rate  of  at 
least  5  times  a  second  while  displaying  more  than  5  colors  at  one 
time . 

A.nglyjsis  of  CuXJC-finJfc  Dig  IS  XN  C.aEfl&ility  -  The  generation  of  the 
terrain  display  using  the  DIGISYN  facility  required  approximately  3-5 
seconds  to  complete.  This  was  far  below  the  0.2  seconds  required  in 
order  to  display  the  scene  at  5  times  per  second.  A  number  of  inhi¬ 
biting  factors  were  found. 

The  central  processor  unit  of  the  DIGISYN  facility  was  a  PDP 
11/45  processor  with  64k  words  of  core  memory  and  32k  words  of  MDS 
memory.  While  this  computer  served  the  laboratory  well  in  driving  the 
airframe  as  well  as  head-up  and  other  display  software,  uhe  added  com¬ 
putational  requirements  of  the  terrain  display  were  beyond  the 
processing  capabilites  of  the  computer. 

Another  limiting  factor  of  the  DIGISYN  system  was  the  graphic 
display  capability.  In  order  to  display  one  frame  of  the  synthetic 
terrain  format,  approximately  17,770  words  of  information  had  to  be 
processed  by  the  RAMTEK  LX-100A  symbol  generator.  This  required 
approximately  1.327  seconds  of  display  time  per  frame  using  a  canned 
scenario  stored  on  magnetic  tape.  It  was  determined  that  increased 
computational  power  coupled  with  a  new  display  processor  could  help 
overcome  some  of  the  display  limitations. 


Tec  rain  Generation  Analysis  -  Because  of  the  large  amount  of  com¬ 
puter  resources  required  to  generate  the  synthetic  terrain  format,  a 
survey  of  available  databases  and  computation  techniques  was  performed 
to  determine  how  the  creation  of  terrain  features  could  be  modified  to 
facilitate  a  real-time  update  rate.  A  database  received  from  the 
Avionics  Laboratory  (AFWAL/AAAT)  was  ultimately  utilized.  This  data¬ 
base  covered  approximately  60x40  nautical  miles  of  Defense  Mapping 
Agency  (DMA)  level  1  data.  The  database  contained  terrain  features, 
but  no  cultural  ones  (i.e.,  no  railroads  or  bridges). 

The  software  used  to  access  this  database  and  generate  the  ter¬ 
rain  features  was  largely  based  upon  the  Terrain  Map  Simulation  (TMS) 
software  received  from  AFWAL/AAAT.  This  software  was  rehosted  on  the 
DIGISYN  system  to  perform  initializations,  navigate  the  aircraft,  and 
generate  the  perspective  veiw  of  the  terrain. 

Using  existing  equations,  it  was  found  that  1.3  seconds  of  compu¬ 
tation  time  on  the  PDP  11/45  was  required  to  calculate  terrain 
altitude  for  the  nominal  30,720  data  points  needed  to  yield  sufficient 
terrain  detail.  A  potential  solution  to  reducing  this  computation 
time  required  the  use  of  an  interpolation  technique.  The  use  of  a 
hardware  polynominal  computation  processor  was  also  considered  as  a 
possible  solution  to  this  problem.  Given  the  definition  of  these  lim¬ 
itations,  a  number  of  hardware  vendors  were  contacted  in  order  to 
determine  if  a  higher  data  transfer  rate,  faster  computational  speed, 
and  greater  amounts  of  main  memory  and  mass  storage  were  viable  solu¬ 
tions  to  the  terrain  generation  update  problems. 


Display  Generation  Analysis  -  In  addition  to  the  terrain  features 
analysis,  an  analysis  of  graphics  display  requirements  was  also  per¬ 
formed.  This  task  included  an  investigation  of  various  display 
techniques  which  could  be  employed  to  generate  terrain  and  cultural 
features  more  expeditiously  than  the  current  implementation  of  the 
format.  A  survey  of  display  hardware  and  software  currently  available 
was  conducted  in  order  to  identify  systems  capable  of  attaining  the 
update  rate,  color,  and  resolution  requirements  of  the  format. 


Upgraded  System  Configuration  Analysis  -  The  results  of  the 
D1GISYN  limitations  analysis,  the  terrain  generation  analysis  and  the 
graphics  display  analysis  were  combined  with  new  timing  and  cost 
information  to  identify  candidate  system  configurations  which  would 
not  only  meet  the  earlier  defined  requirements,  but  would  do  so  with 
the  least  impact  to  the  current  DIGISYN  configuration  and  in  the  most 
cost  effective  manner.  To  achieve  this  goal,  the  following  tasks  were 
performed. 

A.  Information  gathered  on  available  host  and  graphics 
processors  was  analyzed. 

B.  Benchmarks  were  run  on  candidate  host  and  graphics 
processors . 

C.  The  availability  of  interfaces  between  systems  was 
identified. 

D.  Training  and  maintenance  costs  were  defined. 

F.  Software  conversion  costs  were  estimated. 

F.  DIGISYN  adaptability  was  examined. 

Recommendations  -  The  results  of  the  color  terrain  display  system 
analysis  revealed  problems  in  both  the  computational  power  and  graphic 
display  capability  of  the  DIGISYN  system  in  generating  the  terrain 
display.  The  survey  of  the  host  processors  and  graphics  processors 
identified  configurations  with  attributes  to  alleviate  these  problems 
(see  Tables  2. 6. 2-1  and  2. 6. 2-2).  The  following  recommendations  were 
made  to  alleviate  the  update  problems. 

1.  Acquisition  of  a  new  host  processor.  The  VAX  11/780  was 
recommended  as  the  host  processor  for  its  benchmark  speed, 
versatility,  ease  of  software  rehosting,  compati bal ity 
with  current  DIGISYN  configuration,  available  mass  storage 
and  price. 
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Candidate  Host  Processor  Attributes 


2.  Acquisition  of  a  new  graphics  processor.  The  Sanders 
Graphic  8  was  recommended  because  of  its  speed,  polygon  fill, 
3-D  hardware,  16  simultaneous  colors  and  local  storage. 

3.  Update  of  terrain  creation  algorithm.  Modification  of  the 
terrain  creation  algorithm  was  recommended  in  order  to  take 
full  advantage  of  the  new  processor  and  graphic  capabilities. 

4.  Acquisition  of  an  array  processor.  The  purchase  of  an  array 
processor  for  the  new  DIGISYN  system  would  only  be  necessary 
if  the  required  5  times  per  second  display  update  rate  could 
not  be  met  by  following  the  first  3  recommendations.  A 
floating  point  systems  array  processor  was  the  recommended 
choice  because  of  its  high  order  language  compiler  and 
compatibality  with  the  VAX  11/780. 


2.6.3  &P££ch  Applications  (SPA&L  Experiment  guppQXt 

Systems  Control  Technology  provided  systems  integration  support 
needed  to  tie  an  ASTEC  speech  recognition  system  into  the  DIGISYN 
facility  and  support  an  FIGR  experiment  designed  to  investigate  the 
voice  activation  and  control  of  aircraft  displays.  A  functional  over¬ 
view  of  the  SPAM  simulation  setup  is  shown  in  Figure  2. 6. 3-1.  To 
perform  this  integration  process  and  provide  study  support,  the  fol¬ 
lowing  specific  tasks  were  performed. 

PDF  11/50  System  Generation  -  A  now  R5X11-M  Version  3.1  operating 
system  was  generated  for  the  DIGISYN  facility  in  order  to  make  an 
existing  DLll-E  RS232C  interface  port  available  to  both  the  operating 
system  and  user  software.  This  interface  was  used  for  communication 
between  the  DIGISYN  PDP  11/50  computer  and  the  Data  General  Nova  Com¬ 
puter  System  which  served  as  host  to  the  ASTEC  speech  recognition 
system. 
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Noya/PDP  11/ 50  RS23 2  Interface  -  The  Nova  and  PDP  computers  were 
linked  via  an  RS232  communications  line.  SCT  developed  an  interface 
protocol  which  permitted  one-way  communication  from  the  Nova  computer 
to  the  PDP.  The  information  passed  to  the  PDP  computer  consisted  of 
integers  which  represented  words  or  phrases  recognized  by  the  ASTEC 
recognition  system.  An  interface  handler  developed  by  SCT  processed 
these  inputs  and  distributed  them  to  various  existing  DIGISYN  software 
routines  for  further  processing. 

ASTEC  User  Demonstration  Software  -  SCT  developed,  tested  and 
documented  a  user  software  demonstration  package  which  made  use  of 
run-time  software  delivered  with  the  Nova  computer  system.  This 
software  demonstrated  the  capabilities  of  the  ASTEC  system  by  sending 
codes  to  the  PDP  11/50  computer  system  which  represented  keyboard 
switch  hit  information.  Through  the  use  of  this  package,  a  pilot 
could  now  control  the  multifunction  control  display  by  voice  input. 

Modification  of  Existing  DIGISYN  Software  -  The  modification  of 
existing  DIGISYN  software  primarily  consisted  of  general  code  cleanup 
for  better  readability  and  faster  computational  speed.  Some  major 
changes  were  made  however  to  both  the  keyboard  (KEYTES)  and  stores 
status  (STORES)  displays.  While  the  capability  to  change  the  keyboard 
information  by  voice  command  was  the  primary  interest  of  the  experi¬ 
mental  effort,  a  parallel  requirement  of  the  effort  was  the  generation 
of  a  communication  link  between  the  keyboard  and  stores  status  dis¬ 
plays.  This  communication  link  enabled  the  pilot  to  receive  immediate 
pictorial  feedback  of  any  weapon  option  changes  made  on  the  multifunc¬ 
tion  keyboard  display.  Also,  the  routine  which  defined  the  weapon 
load  for  the  stores  status  display  was  completely  rewritten. 
Previously,  the  stores  status  display  could  only  reflect  a  weapon  load 
that  was  predefined  and  stored  as  data  in  a  data  file.  The  new 
routine  was  written  to  query  the  system  common  area  of  memory  for 
weapon  load  information  every  Lime  this  data  was  updated  by  the  key¬ 
board  software.  The  resulting  effort  was  an  immediate  stores  status 
display  update  for  every  weapon  option  change  made  by  the  pilot. 
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Changes  nude  to  other  existing  DIGISYN  software  included  the  mod¬ 
ification  of  the  data  scoring  and  data  reduction  routines,  changes  to 
the  keyboard  switch  counting  and  scoring  routine,  and  minor  modifica¬ 
tions  to  the  mission  setup,  general  purpose  control  and  display  switch, 
processing  and  system  common  memory  tasks. 

With  the  completion  of  the  software  modifications,  the  entire 
simulation  software  package  was  assembled  and  integrated. 
Modifications  were  made  in  both  the  overall  timing  of  the  simulation 
software  and  the  amount  of  memory  allocated  to  the  operating  system. 
With  the  increased  input  and  output  demands  made  by  the  simulation 
software,  it  was  determined  that  more  memory  was  needed  for  operating 
system  storage.  The  system  was  modified  to  provide  the  operating  sys¬ 
tem  with,  an  ample  input/output  memory  pool. 

Experiment  Support  -  During  the  course  of  the  experiment,  SCT 
srovidud  programming  support  and  experiment  operator  support  as 
required.  The  support  encompassed  "quick-fix"  software  changes,  sta¬ 
tion  operation  support,  and  systems  engineering  support  in 
pc r  .i  mental  set-up  and  data  reduction.  During  the  analysis  of  the 
pei.  imental  data,  it  was  determined  that  the  time  lag  between  voice 
lucognilion  and  actual  display  change  must  be  measured.  SCT  developed 
, preach  to  measuring  this  lag  and  generated  a  computer  program  for 
tar  ..dual  measurements.  Multiple  time  lag  measurements  were  made 
under  all  experimental  conditions  and  the  results  were  reported  to 
!■'  i  C  K . 

J . 6 . 4  Flat  Panel  Pi spl ay 

The  United  States  Air  Force  and  the  Canadian  Government  of  lndus- 
ir,.  Trade  and  Commerce  has  a  memorandum  of  agreement  which  supports 
i ne  joint  development,  fabrication,  test  and  evaluation  of  a  Flat 
Pare ;  !  i'dit  I. cutting  Diode  (LSD)  Multi-Mode  Matrix  (MMM)  display  (see 

idem  P..F.4- 1).  The-  development  of  this  technology  would  test  the 
porsibi  1  i  ty  ■ .  i  l  nq  a  multipurpose  display  of  this  type  on  instrument 
panel,  in  ui  i  or ...  i  t  r/kpits  for  the  presentation  of  real-time  flight 
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parameter  and  system  status  information.  In  support  of  the  evaluation 
of  this  device,  SCT  participated  in  conducting  a  ground  based  aircraft 
simulation  using  the  MMM  display. 

The  DIGISYN  facility  in  AFWAL/FIG  was  used  for  the  simulation 
experiment.  In  conducting  this  study,  a  new  set  of  simulation 
software  was  written  to  interface  the  MMM  display  system  to  the 
DIGISYN  PDP  11/50  computer  system  and  to  interface  the  PDP  11/50  to  a 
PDP  11/55  computer  system  (see  Figure  2. 6. 4-2).  The  simulation  also 
required  the  use  of  existing  DIGISYN  software,  which  was  modified 
accordingly.  The  following  sections  describe  both  the  generation  of 
the  new  software  and  modification  of  the  existing  software. 

MMM  Software  -  The  new  software  generated  for  the  MMM  experiment 
effort  was  divided  into  four  parts.  They  were  1)  the  MMM  simulation 
executive  control  programs,  2)  the  MMM  interface  control  program,  3) 
the  MMM  formatter  program  and  4)  the  DA11BJ  transfer  software  program. 
Each  of  these  is  described  in  the  following  sections. 

•  MMM  Simulation  Executive  Control  Programs  -  To  accomplish  all 
of  the  tasks  required  of  the  MMM  simulation  software,  a  decision 
was  made  to  utilize  two  PDP  11  processors.  The  DIGISYN  PDP  11/50 
served  as  the  master  executive  processor  and  a  PDP  11/55  located 
in  the  Crew  Station  Integration  Laboratory  served  as  the  slave 
executive  processor.  Two  separate  computer  programs  were  written 
to  serve  as  executive  control  routines  for  the  interface  of  the 
two  computer  systems.  The  responsibility  of  each  computer  pro¬ 
gram  was  to  provide  a  communication  link  between  its  own  computer 
system's  common  area  of  memory  and  a  DA11B-J  hardware  interface 
connecting  the  two  computers.  Additional  responsibilities  of  the 
master  executive  program  included  the  control  of  all 
analog-to-digi tal  input,  digi tal-to-analog  output,  MMM  formatter 
software,  MMM  interface  control  software  and  scheduling  of  the 
data  recording  software.  The  primary  task  of  the  slave  executive 
program  was  to  schedule  and  control  the  aeromodel  software. 
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•  MMM  Interface  Control  Program  -  A  total  of  13  different 
software  routines  were  written  to  perform  the  input  and  output 
control  between  the  DIGISYN  PDP  11/50  computer  and  the  MMM  com¬ 
puter.  Of  these  13  routines,  one  served  as  the  executive  program 
that  scheduled  2  routines  for  initialization,  3  routines  to  send 
and  receive  data  messages  to  and  from  the  MMM  computer,  and  7 
routines  to  identify  errors  and  take  appropriate  error  action. 
All  transfers  of  data  were  accomplished  using  a  DRll-B  Direct 
Memory  Access  (DMA)  hardware  interface.  The  communication  proto- 
cal  for  all  input  and  output  was  defined  in  the  MMM  Interface 
Protocal  Document  supplied  by  the  manufacturer  of  the  MMM  Display 
and  computer. 


•  MMM  Formatter  Program  -  A  total  of  9  software  routines  were 
written  to  perform  the  formatting  of  displays  for  the  MMM  com¬ 
puter.  These  displays  include  an  engine  status  indicator,  an 
electronic  attitude  direction  indicator,  an  electronic  horizontal 
situation  display,  a  navigation  indicator,  and  a  precision 
approach  indicator.  Of  these  5  different  formats,  only  one,  the 
electronic  attitude  direction  indicator,  was  used  during  the 
evaluation  of  the  MMM  display.  In  addition  to  the  5  routines 
which  actually  formatted  the  displays,  one  routine  was  written  to 
serve  as  an  executive  controller  and  scheduler,  one  routine  was 
written  for  the  initialization  of  all  display  flags  and  scale 
factors,  another  performed  a  checksum  of  the  entire  output  data 
buffer,  and  a  fourth  was  written  to  allow  the  MMM  computer  to 
generate  a  given  unspecified  format  of  an  experimental  or  trial 
nature . 

Each  of  the  9  routines  was  written  in  FORTRAN  and  was 
designed  to  run  on  the  DIGISYN  PDP  11/50  computer.  Each  of  the 
formatting  routines  generated  an  integer  buffer  of  data  for  the 
MMM  that  was  fully  responsive  to  the  interface  control  software. 


171 


•  DA11B-J  Transfer  Software  -  Two  programs  were  written  to  con¬ 
trol  the  transfer  of  data  through  the  DAllB-J  hardware  that 
connected  the  PDP  11/50  and  PDP  11/55  computers.  The  master 
transfer  software  resided  on  the  PDP  11/50  and  was  used  by  the 
master  executive  control  routine  to  initiate  the  transfer  of  data 
to  the  slave  PDP  11/55  computer  at  a  50  Hertz  rate.  Upon  recep¬ 
tion  of  data  from  the  master  processor,  the  slave  transfer 
software  residing  on  the  PDP  11/55  was  used  to  initiate  a 
response  transfer  of  data  back  to  the  master  computer.  Both  of 
these  programs  were  written  in  the  PDP  11  assembly  (MACRO) 
language  and  were  designed  to  execute  under  the  RSX-11M  V3.1 
operating  system.  Both  programs  were  directly  controllable  only 
from  the  executive  control  programs  of  each  computer  system. 


Modification  of  Existing  DIGISYN  Software  -  In  order  to  carry  out 
the  simulation  testing  of  the  MMM  display,  various  existing  programs 
residing  on  the  DIGISYN  computer  system  had  to  be  utilized.  It  was 
necessary,  though,  to  modify  these  programs  to  meet  the  specific 
requirements  of  the  software  effort. 

The  mission  setup  software  was  changed  to  reflect  the  new  experi¬ 
mental  matrix.  Other  changes  involved  the  initialization  of  various 
flags  for  MMM  control  and  the  repositioning  of  the  aircraft  to  an  ini¬ 
tial  condition  of  10000  feet  altitude,  300  kts  airspeed  and  0  degrees 
heading . 

The  data  recording  software  was  extensively  modified  for  the  MMM 
simulation  effort.  Under  typical  simulation  studies  run  on  the 
DIGISYN  facility,  the  data  recording  software  handled  the  collection 
of  flight  performance  data  during  both  a  pre-event  and  event  phase. 
This  software  also  normally  contained  some  logic  used  for  the  collec¬ 
tion  of  keyboard  switch  information.  To  attain  greater  computational 
speed,  much  of  the  code  pertaining  to  these  capabilities  was  deleted, 
since  neither  were  required  in  this  simulation.  Some  logic  was  added 
though  for  the  complete  control  of  the  data  recording  process  by  the 
master  executive  control  program. 

The  status  display  provides  the  experimenters  with  feedback  per- 


taining  to  the  current  state  of  the  mission,  software  and  pilot 
activities.  The  status  display  software  for  the  MMM  experiment  was 
completely  rewritten  to  provide  the  experimenters  with  information 
concerning  matrix  number,  pilot  number,  treatment  number,  avionic  and 
MMM  display  update  rates,  current  maneuver  number,  slave  status,  G 
loading,  and  DAllB-J  status. 

The  aeromodel  was  rehosted  on  the  PDP  11/55  slave  processor.  The 
executive  control  program  for  the  aeromodel  was  converted  from  a  pro¬ 
gram  to  a  subroutine  so  that  direct  control  could  be  obtained  by  the 
slave  executive  program.  The  integration  rates  of  many  key  routines 
were  modified  so  that  the  areomodel  would  perform  at  a  50  Hertz  update 
rate.  A  pitch  damper  was  added  to  the  aeromodel  and  the  roll  damper 
was  modified  for  more  realistic  flight  performance  during  aerobatic 
maneuvers.  Minor  changes  to  the  aircraft's  coefficient  of  lift  and 
center  of  gravity  parameters  were  made  in  the  interest  of  improved 
handling  quality. 

2.6.5  Pictorial  Emergency  Procedures/Speech  Interaction 

The  Crew  Systems  Development  Branch  of  the  Air  Force  Wright  Aero¬ 
nautical  Laboratory  ( AFWAL/F IGR)  performed  a  Pictorial  Emergency 
Procedure  Speech/Integration  (PEPSI)  study  which  compared  different 
methods  of  communicating  emergency  procea^res  to  the  pilot.  The  emer¬ 
gency  procedures  were  communicated  using  the  following  three  methods. 

A)  A  pictorial  display  depicting  the  emergency  and  the 
recommended  emergency  procedure. 

B)  An  alph-^umer ic  display  presenting  the  emergency 
procedures  in  a  text  format. 

C)  An  aural  warning  and  checklist  presented  by  the  computer 
in  machine  generated  speech. 
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needed  to  tie  Discovision  video  players  into  the  DIGISYN  facility, 
programming  support  needed  to  generate  the  alphanumeric  display  and 
PDP/NOVA  communication  driver  software  and  systems  integration  support 
needed  to  tie  the  newly  developed  software  into  the  existing  DIGISYN 
software  package.  An  overview  of  the  new  software  generated  for  PEPSI 
is  shown  in  Figure  2. 6. 5-1.  The  following  specific  tasks  were  per¬ 
formed. 

RSX-11M  System  Generation  -  A  new  RSX-11M  system  generation  was 
performed  for  the  DIGISYN  PDP  11/50  computer  system.  This  new  operat¬ 
ing  system  was  required  in  order  to  make  use  of  a  DZll  multiplex  line 
interface  purchased  for  communication  with  the  Discovision  vodeodisc 
players.  All  other  hardware  used  for  the  previous  simulation  effort 
(SPAM)  was  included  in  the  new  system. 

PDP  11/M  -  NOVA  Communication  Software  -  Three  assembly  (MACRO) 
language  routines  (NOVA)  were  written  to  provide  a  generalized  inter¬ 
face  to  an  RS-232  channel  through  a  PDP-11  interface  card. 
Collectively,  these  routines  made  up  the  DL11  MACRO  program  which  han¬ 
dled  all  communication  between  the  PDP  and  NOVA  computer  systems.  All 
three:  routines  were  interrupt  driven  and  used  the  RSX-11M  connect  ser¬ 
vice  to  intercept  the  interrupts.  An  I/O  page  mapping  routine  was 
written  to  provide  access  to  the  DLll  registers.  In  order  to  provide 
this  specialized  control  over  the  DLll  interface  card,  the  operating 
system  was  not  informed  of  the  presence  of  the  DLll  at  the  time  of  the 
SYSGEN. 


NOVA  Computer  Software  -  The  main  purpose  of  the  software  gen¬ 
erated  on  the  NOVA  computer  was  to  provi.de  two-way  communication 
between  the  pilot  and  the  voice  recognition/generation  system.  During 
those  experimental  conditions  where  the  pilot  was  commanding  the  cock¬ 
pit  by  voice  control,  the  NOVA  software  was  used  to  control  the  ASTEC 
recognition  software.  In  the  experimental  conditions  where  machine 
generated  voice  responses  were  required,  the  NOVA  software  communicat¬ 
ed  with  the  DIGISYN  computer  to  obtain  a  number  corresponding  to  the 
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phrase  to  be  generated,  and  then  passed  this  data  along  to  the  voice 
generation  software  for  output. 

Four  specific  routines  were  written  for  the  NOVA  computer  system. 
They  were:  PEPl,  the  executive  controller;  LPDP,  the  routine  used  to 
communicate  with  the  PDP;  LSUS,  a  routine  which  "listened"  for  pilot 
voice  commands;  and  LKEY,  a  routine  which  processed  inputs  from  the 
NOVA  computer  terminal. 

Alphanumeric  Display  Sof tware  -  In  one  of  the  experimental  condi¬ 
tions,  the  pilot  was  provided  with  an  alphanumeric  display  showing  the 
actions  required  in  response  to  a  pseudo  emergency  cockpit  condition. 
A  general  purpose  routine  ( RTTEXT)  was  written  which  built  a  vector  of 
KAMTEK  commands  needed  to  display  the  ASCII  text  on  a  cockpit  monitor. 
Functions  such  as  clearing  the  display  and  changing  text  color  were 
built  into  the  software  and  controlled  through  the  calling  sequence. 


Discovision  Display  Software  -  In  one  of  the  experimental  condi¬ 
tions,  the  pilot  was  provided  with  a  display  pictorially  showing  the 
actions  required  in  response  to  a  pseudo  emergency  cockpit  condition. 
The  pictures  presented  to  the  pilot  had  previously  been  recorded  on 
video  disc  and  could  be  identified  by  a  specific  frame  number. 
Software  (DISPIC)  was  written  which  established  communication  betweer 
the  PDP  host  computer  and  a  microprocessor  built  into  the  video  disc 
player  unit.  Once  communication  was  established,  the  video  disc 
players  were  commanded  to  display  the  pictures  required  of  the  specif¬ 
ic  emergency  task. 

Throughout  each  experimental  flight,  the  pilot  also  had  at  his 
disposal  a  stores  status  picture  generatec  by  a  second  videc  disc 
unit.  Unlike  the  emergency  displays,  the  stores  status  picture  was 
always  shown  and  represented  the  current  state  of  the  aircraft's 
external  stores.  A  routine  (STORES)  was  written  to  gather  stores 
information  from  the  DIGISYN  multifunction  control  display,  determine 
if  a  video  disc  picture  existed  that  represented  the  current  stores 
status,  and  if  so,  command  the  video  disc  unit  to  display  that  pic¬ 
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All  of  the  videodisc,  NOVA  computer,  and  RAMTEK  communication 
software  was  controlled  by  a  set  of  executive  control  routines 
(CONTRL)  also  written  in  support  of  the  PEPSI  software  effort.  These 
executive  control  routines  were  needed  to  schedule  all  communication 
with  the  PDP  computer  system  so  that  no  information  would  be  lost. 

Modification  of  DIGISYN  Software  -  One  of  the  goals  of  every 
software  development  effort  on  the  DIGISYN  facility  was  to  create 
software  that  could  be  used  not  only  for  the  current  study,  but  for 
future  studies  as  well.  The  PEPSI  software  package  benefitted  from 
this  philosophy  by  making  use  of  the  aeromodel,  data  recording,  data 
reduction,  multifunction  keyboard,  and  flight  display  software  used 
for  the  Speech  Applications  to  Multifunction  Control  (SPAM)  study. 

Because  these  routines  were  used  with  an  operating  system  with  a 
100  Hertz  clock,  all  self-scheduled  routines  were  modified  for  use 
with  the  60  Hertz  clock  being  used  in  the  PEPSI  study.  The  following 
describes  the  additional  modifications  made  to  the  existing  DIGISYN 
so  f  twar e . 


•  AFLOAD  -  The  aeromodel  software  was  modified  to  provide  a  20% 
increase  in  drag  to  better  reflect  aircraft  performance  with  the 
stores  load  required  in  the  mission.  All  code  pertaining  to 
digital  ^o  analog  calculations  was  commented  out.  Calls  to  the 
namelist  were  also  commented  out. 

•  DATA!  -  The  data  recording  software  was  modified  to  reference 
the  specific  performance  variables  needed  for  this  study. 
Additional  logic  was  added  to  this  data  recording  routine  for 
communication  to  both  the  executive  control  software  and  the  mul¬ 
tifunction  control  display  software. 

•  DATA2  -  The  data  reduction  software  was  modified  only  slightly. 
The  output  data  file  name  was  changed  to  PEPSI.DAT,  the  baseline 
airspeed  reference  was  changed  to  480  knots,  ana  all  routines 

"cleaned  up"  by  removing  references  to  variables  not  used. 
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•  ENG  -  The  majority  of  routines  that  make  up  the  engine  display 
software  had  to  be  modified  because  they  had  not  been  used  in 
recent  studies.  Access  to  the  system  common  area  at  memory  and  th 
use  of  Include  statements  was  changed.  To  make  the  software  more 
efficient,  all  code  for  generation  of  a  monocrome  engine  display 
was  removed,  as  was  code  for  communication  with  the  caution  warn¬ 
ing  panel  and  code  for  engine  shutdown.  New  code  was  added  to 
the  engine  display  software  for  communication  with  the  executive 
control  task.  This  new  code  enabled  the  display  to  provide  the 
pilot  with  alphanumeric  feedback  during  an  emergency  task. 
Modifications  to  the  display  format  included  limiting  the  fuel 
flow  bar  to  5300  LB  hi  .  :•  1  .1 r  the  kP.M  .  I  1::.  stirs.:  the  i<YK<  10  .1  r 

-  '  ;  ;  :  -gior.s  t  or  1  ay  or  hydraulic 


©  FI.TDIR  -  The  flight  director  software  was  modified  to  go  to 
waypoint  16  at  track  advance  and  to  direct  the  pilot  to  the  tar¬ 
get  rather  than  a  release  point  near  the  target.  Access  to  the 
oicb  LED  display  through  the  use  of  a  namelist  was  reactivated. 

•  in1 1 j  -  Most  of  the  modifications  made  to  the  head  up  display 
sol Lwuro  involved  adding  a  check  for  a  flight  master  mode  of  4. 
This  allowed  the  use  of  the  integrated  HUD  symbology  while  in  the 
NAV  BOMB  mode.  Four  new  Legends  were  added  to  the  HUD  legend 
data  set  to  reflect  changes  made  to  the  multifunction  control 
display.  The  pull-up  queue  (the  big  X)  was  disabled  during 
we a  pop  del i v er y . 


•  KBYTES  -  The  mul  t  i  J  unction  control  display  software  was  modi¬ 
fied  to  ci 1  ermine  whether  switch  inputs  were  coming  from  voice  or 
manual  control.  Some  of  the  legends  on  the  stores  display  were 
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The  task 


current  experiment  task  sequences.  All  task  tables  were  generat¬ 
ed  . 

•  MSNSET  -  The  majority  of  changes  made  to  the  mission  setup 
software  involved  the  modification  of  the  waypoint  locations  and 
weapon  loads.  The  keyboard  scoring  task  table  information  was 
also  modified.  Various  switch  flag  settings  were  also  changed 
for  proper  initializations  of  the  aeromodel  and  cockpit  status 
displays . 

•  STATUS  -  The  experimenter's  status  display  software  was  modi¬ 
fied  extensively  to  present  task  and  flight  performance  data. 
The  software  was  written  so  that  the  status  display  would  be 
self-scheduled  at  a  one  Hz  rate. 

2.6.6  Microprocessor  Application  of  Graphic  and  Interface 
Communication 

SCT  supported  the  development  of  a  dynamic  mockup  which  was  used 
for  testing  possible  applications  of  color  flight  displays  and  voice 
technology  for  the  Advanced  Tactical  Fighter  of  the  future.  The  ini¬ 
tial  configuration  of  MAGIC  consisted  of  four  microprocessors,  two 
graphics  systems,  hard  and  floppy  disc  drives,  video  disc  systems,  a 
Votan  voice  recognition/generation  system,  a  Colecovision  game,  color 
monitors,  test  operator's  console,  and  required  hardware  interfaces. 
PCT  was  specifically  tasked  with  the  development  of  data  recording, 
data  reduction  and  aeromodel  software  for  the  MAGIC  system.  All 
soft. ware  was  written  in  the  PASCAL  language  using  an  MPM  operating 
system.  The  following  tasks  voire  performed. 

ffAlVRLC  Software  Development:  -  The  data  recordino  software 
developed  for  the  MAGIC  system  was  written  to  ta,.c  flight  per  f  ormanct. 
and  voice/keyboa  rd  switch  hit  data  supplied  by  the  seal:'.:  ;i  ana 
store  this  information  in  a  file  on  a  pseudo-disc  in  sequential  record 
format.  The  specific  data  collected  were  switch  mode  (voice  or  key- 
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board),  mission  code,  pilot  number,  matrix  number,  task  number,  task 
code,  deviation  from  commanded  airspeed,  deviation  from  commanded 
pitch  angle,  deviation  from  commanded  bank  angle,  number  of  switch 
inputs,  number  of  switch  inputs  expected,  time  to  initiate  a  task  and 
total  task  time.  The  design  of  the  software  allowed  for  the  collec¬ 
tion  of  the  airspeed,  bank  and  pitch  deviation  measures  at  a  rate  of 
up  to  10  samples  per  second.  All  other  data  were  collected  as  needed. 

The  DATREC  routine  was  written  as  a  PASCAL  procedure  callable  by 
any  executive  program,  assuming  the  calling  program  had  access  to  the 
data  that  were  being  collected.  All  data  were  defined  as  global  vari¬ 
ables,  eliminating  the  necessity  of  calling  arguments. 

DATA2  Software  Development  -  The  data  reduction  software  written 
for  the  MAGIC  system  was  a  logical  extension  of  the  data  recording 
software.  DATA2  was  written  to  convert  the  raw  flight  performance  and 
voice/keyboard  switch  hit  data,  placed  in  a  file  by  DATREC,  into  sum¬ 
mary  statistics  for  output  to  both  a  floppy  disc  and  hard  copy 
printer.  The  summary  statistics  included  average  error,  absolute 
average  error,  rootmean  square  and  standard  deviation  of  horizontal 
steering,  vertical  steering,  and  airspeed  errors  for  both  pre-event 
and  event  data. 

Unlike  the  data  recording  software,  which  was  written  as  one 
callable  PASCAL  procedure,  the  DATA2  software  consisted  of  a  main  pro¬ 
gram  with  four  procedures  which  was  either  chained  to  an  executive 
control  program  or  called  as  a  stand-alone  program. 

AFLOAD  Software  Development  -  The  aeromodel  software  hosted  on 
the  MAGIC  system  consisted  of  13  PASCAL  procedures  stored  in  11 
modules  that  were  used  to  solve  the  equations  of  motion  of  an  A-7D 
close  air  support  fighter  aircraft.  The  program  was  designed  to  run 
nominally  at  a  10  Hz  or  faster  rate  and  had  four  modes  of  operation. 
They  were  Standby,  IC,  Trim,  and  Run. 

In  the  standby  mode,  no  dynamic  programs  were  called  or  updated. 
This  allowed  the  aircraft  to  essentially  be  "frozen"  in  any  current 
state  or  flight  condition.  The  Initial  Condition  (IC)  mode  was  used 


to  initialize  the  simulation  integrations  and  timers  to  a  "time  zero" 
state  via  a  simulation  control  panel.  All  of  the  simulation  dynamic 
programs  were  called  in  this  IC  mode.  Each  routine  was  written  to 
perform  its  own  initialization  process.  The  Trim  mode  was  an  interim 
mode  where  the  program  trimmed  the  aeromodel  to  straight  and  level 
flight  at  the  specified  conditions.  The  Run  mode  allowed  the  update 
of  each  of  the  routines  at  a  10  Hz  update  rate.  The  "airplane"  was 
flown  in  this  mode.  The  aeromodel  software  was  actually  a  FORTRAN  to 
PASCAL  conversion  of  the  aeromodel  software  written  for  the  DIGISYN 
facility.  For  the  most  part,  the  logic  was  not  changed  during  the 
conversion.  A  decision  was  made  to  attempt  to  retain  the  actual  code 
wherever  possible  in  order  to  minimize  the  risk  of  corrupting  the 
logic. 

In  an  effort  to  retain  as  much  flexibility  as  possible,  switch 
flags  were  retained  to  control  the  various  parts  of  the  aeromodel 
software.  The  control  over  these  switch  flags  was  attained  via  a  con¬ 
trol  terminal. 

2.6.7  Advanced  Control/Disolav  Conclusions  and  Recommendations 

In  supporting  the  Advanced  Control  and  Display  effort  at  WPAFB , 
we  found  that  our  role  in  the  work  being  performed  in  the  laboratory 
not  only  encompassed  the  realm  of  software  development,  but  also 
involved  the  areas  of  systems  analysis  and  systems  engineering.  In 
many  cases,  the  level  of  support  needed  for  a  simulation  development 
task  included  much  knowledge  of  the  hardware  being  used  in  the  effort 
as  well  as  an  understanding  of  the  experimental  design  and  statistical 
techniques  being  used  in  the  study.  SCT  felt  very  comfortable  in  all 
areas  of  the  experimental  effort  because  of  the  diversity  and  experi¬ 
ence  of  the  SCT  staff.  For  example,  in  developing  the  data  recording 
and  data  reduction  software  for  the  MAGIC  system,  a  number  of  discip¬ 
lines,  other  than  simple  software  coding,  had  to  be  represented.  Even 
though  the  software  routines  were  developed  using  the  existing  DIGISYN 
software  as  a  model,  the  task  was  not  one  of  a  straight  FORTRAN  to 
PASCAL  conversion.  This  task  required  knowledge  of  the  hardware  being 
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used  for  data  storage,  an  idea  of  the  number  and  types  of  data  to  be 
collected,  and  an  understanding  of  the  phases  of  data  collection  and 
frequency  of  collection.  The  ramifications  of  collecting  data  too 
frequently  or  too  infrequently  had  to  be  analyzed.  In  developing  the 
data  reduction  software,  some  knowledge  of  statistics  was  required  to 
arrive  at  the  best  equations  for  "collapsing"  the  data.  Some  human 
factors  input  was  also  needed  to  produce  a  final  result  that  was  easy 
to  read  and  easy  to  interpret,  but  also  compatible  with  existing  data 
analysis  programs. 

Not  only  was  a  diversity  of  experience  required  for  this  timely 
completion  of  any  assigned  task,  we  feel  that  adequate  planning  was  an 
equally  important  prerequesite  for  satisfactory  task  completion. 
Before  any  software  was  written,  we  felt  that  requirements  analysis 
should  be  done  to  identify  the  problem  at  hand  and  to  devise  an 
approach  to  the  development  of  any  software.  In  a  few  instances,  a 
general  task  was  defined,  but  no  exact  specification  was  included. 
For  example,  during  the  MMM  simulation  software  development  effort, 
SCT  was  required  to  provide  an  experimenter's  status  display.  It  was 
known  that  some  type  of  mission  phase  data  would  be  displayed  as  well 
as  feedback  showing  what  the  pilot  was  doing  and  what  the  hardware  and 
software  were  doing  at  any  given  time  during  the  experiment,  but  a 
specific  display  format  was  not  identified.  Before  any  software  was 
written,  a  proposed  status  display  format  was  developed  and,  through 
an  interative  process,  the  final  format  was  agreed  upon.  From  this 
final  product,  the  specific  requirements  were  defined  and  the  coding 
of  the  software  went  quickly  and  efficiently. 

A  major  component  of  this  iterative  process  was  the  ease  of  com¬ 
munication  between  all  involved  participants.  Weekly  status  meetings 
with  all  involved  participants  were  found  to  be  extremely  helpful  in 
the  development  of  the  simulation  package.  During  these  meetings, 
problems  were  discussed  which  potentially  impacted  the  work  of  other 
simulation  team  members.  By  presenting  these  problems  to  everyone 
involved,  a  solution  was  generally  reached  in  a  rather  expedient 
manner.  The  biggest  lesson  learned  from  these  simulation  efforts  was 
the  need  for  open  communication.  The  answers  to  potential  stumbling 


blocks  were  many  times  only  a  telephone  call  away. 

Regj?nun.e.n.dfl.tiQns  Lql  tji£  Future 

During  every  simulation  effort,  minor  problems  arose  which  at 
times  hampered  the  development  of  the  simulation  software.  The  prob¬ 
lem  which  most  frequently  impacted  the  simulation  schedule  was  the 
failure  of  system  hardware.  In  almost  every  study  run  using  the 
DIGISYN  facility,  the  display  generating  hardware  malfunctioned. 
Section  2.6.2  describes  the  recommendations  made  in  this  area. 

In  the  MAGIC  system,  the  needs  seem  to  be  in  two  areas.  The 
first  area  of  focus  for  the  future  should  be  in  the  upgrading  of  both 
the  processing  and  graphics  generating  hardware.  The  facility  as  it 
stands  now  does  an  excellent  job  of  handling  the  research  currently 
undertaken  in  the  static  and  slow  dynamic  display  areas.  However, 
future  research  in  the  highly  dynamic  aircraft  simulation  area  will 
require  hardware  that  can  process  equations  of  motion  and  graphics 
generation  software  at  speeds  much  higher  than  are  currently  being 
attained. 

Another  avenue  of  future  growth  recommended  for  the  advanced  con¬ 
trols  and  displays  research  efforts  is  the  development  of  a  data 
analysis  capability.  Currently,  the  majority  of  simulation  data  must 
be  transferred  to  a  large  mainframe  computer  for  one  phase  of  the  data 
analysis,  and  transferred  to  a  second  mainframe  computer  for  addition¬ 
al  analysis.  The  transfer  of  raw  data  to  these  machines  has  not  been 
a  trivial  matter.  The  on-line  access  to  these  machines  has  at  times 
been  another  problem.  A  fully  capable  analysis  package  which  resides 
on  the  simulation  system  might  be  a  desirable  goal  for  the  future. 
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2.7  AFTI/F-111  PROGRAM 


2.7.1  Program  Background  and  Goals 

The  mission  adaptive  wing  (MAW)  design  goal  is  to  maintain  aero-  ! 

dynamic  efficiency  at  all  speeds  and  in  all  flight  modes  in  response 
to  various  flight  conditions  and  pilot  commands.  This  is  to  be 
achieved  by  using  variable  camber  wings  with  smooth,  flexible  leading  ^ 

and  trailing  edges  (i.e.,  no  spoilers,  flaps,  or  fairings  to  break  the 
upper  and  lower  surface  contours) .  The  flexible  leading  edge  is  one 
continuous  segment,  and  the  flexible  trailing  edge  is  divided  into 
separate  segments  for  roll  control  and  for  shifting  the  aerodynamic  ■ 

load.  Figure  2.7-1  shows  a  pictorial  of  the  AFTI/F-111  MAW  configura¬ 
tion. 

The  MAW  is  designed  to  be  a  wing  for  all  flight  conditions.  The 
cross-section  shape  of  the  wing  can  be  changed  by  an  actuation  system  j 

confined  within  the  airfoil  shape.  The  wing  shape  can  thus  be  changed 
to  give  optimum  performance  for  a  given  flight  condition  including 
take-off/landing,  subsonic,  transsonic,  or  supersonic  conditions.  The 
variable  camber  control  offers  (1)  cruise  camber  control  to  minimize  j 

drag,  (2)  roll  control  without  spoilers,  (3)  maneuver  load  allevia¬ 
tion,  (4)  gust  alleviation,  and  (5)  direct  lift.  The  principal 
benefits  from  these  features  are  better  maneuverability,  longer  range, 
greater  fuel  efficiency,  and  improved  handling  qualities.  For  the  j 

combat  pilot,  the  MAW  means  faster  evasive  action,  increased  surviva¬ 
bility,  a  more  stable  platform  for  weapon  delivery,  and  a  more 
comfortable  ride  to  reduce  crew  fatigue  and  allow  better  performance. 

Aerodynamic  control  of  the  AFTI-F-111  will  be  accomplished  by  j 

movement  of  the  wing  leading  and  tailing  edge  variable  camber  control 
surfaces,  the  stabilons  and  rudder.  Control  of  the  wing  surfaces  will  ; 

be  achieved  via  the  MAW  FCS.  Stabilon  and  rudder  control  will  be  " 

achieved  via  the  existing  TACT-F-111  FCS  modified  for  the  MAW  applica-  j 

tion.  Three  configurations  of  the  MAW  FCS  will  be  provided;  an  all 
manual  control  configuration,  followed  by  a  manual  plus  a  maneuver 
camber  control  and  cruise  camber  control  system  and  finally  a  manual 
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plus  full  automatic  configuration. 

The  MAW  FCS  will  use  a  redundant  electronic  system  consisting  of 
analog  and  digital  circuit  technology.  The  system  will  provide  fail 
safe  leading  edge  control  and  fail  operational  control  after  one 
failure  for  the  trailing  edge  roll  control  surfaces.  Functions  per¬ 
formed  will  include  control,  display,  fault  detection,  isolation  and 
built-in  test.  The  MAW  FCS  will  provide  the  interface  between  the 
pilot  and  the  control  surfaces  in  both  the  manual  and  automatic 
operating  modes.  Figure  2.7-2  presents  a  sketch  of  the  wing  assembly 
while  Figure  2.7-3  is  a  schematic  diagram  of  the  flight  control  system 
showing  each  major  function  of  the  system  which  controls  the  wing 
assembly. 

2.7.2  Program  Description 

The  Advanced  Fighter  Technology  Integration  (AFTI)  F-lll  Program 
consists  of  two  phases.  The  first  phase  addresses  the  design  and 
development  of  a  variable  camber  (VC)  mission  adaptive  wing  (MAW)  and 
includes  a  flight  test  program.  Testing  of  the  MAW  will  be  performed 
using  a  manual  pilot-controlled  fly-by-wire  system  for  setting  MAW 
leading  and  trailing  edge  deflections.  This  manual  system  provides 
for  evaluation  of  general  quasi-static  aerodynamic  performance  and  for 
developing  flight  control  parameters. 

Phase  two  of  the  AFTI-F-111  Program  addresses  the  design  and 
development  of  a  modification  to  incorporate  an  automatic  flight  con¬ 
trol  system  (AFCS)  capability  for  the  MAW  that  is  compatible  with  the 
manual  control  system.  A  second  flight  test  program  is  planned  to 
evaluate  the  MAW  with  automatic  controls  and  demonstrate  the  perfor¬ 
mance  benefits  provided  by  the  AFCS  functions. 

2. 7. 2.1  MAW  Manual  Flight  Control  System 


The  manual  flight  control  system  (MFCS)  phase  of  the  MAW  program 
includes  the  design  and  development  of  a  variable  camber  wing  and 
flight  test.  Modifications  have  been  made  to  the  pitch,  roll,  and  yaw 
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Figure  2.7-3  MAW  Flight  Control  System  Schematic  Diagram 


channels  of  the  TACT/F-111  flight  control  in  order  to  incorporate  the 
control  characteristics  of  the  MAW.  Additionally,  a  MFCS  has  been 
developed  to  drive  and  control  the  leading  and  trailing  edge  surfaces. 
The  initial  system  configuration  provides  manual  control  of  the  lead¬ 
ing  and  trailing  edge  control  surfaces  in  symmetrical  pairs,  provides 
roll  control  via  outboard  and  mid  span  trailing  edge  surfaces  and  pro¬ 
vides  means  to  establish  the  takeoff  and  landing  configuration.  The 
MAW  FCS  has  a  dual  digital  architecture  that  provides  primary  control 
of  the  MAW  control  surfaces.  A  segregated  analog  system  provides  for 
backup  roll  and  limited  trailing  edge  symmetric  control  for  landing  in 
the  event  of  primary  system  failure. 

2. 7. 2. 2  MAW  Automatic  Flight  Control  System 

The  AFCS  modes  are  added  to  the  existing  manual  flight  control 
system  to  augment  the  performance  of  the  aircraft.  The  fou'.  AFCS 
modes  added  are: 

1.  Maneuver  Camber  Control  (MCC) 

2.  Cruise  Camber  Control  (CCC) 

3.  Maneuver  Load  Control  (MLC) 

4.  Maneuver  Enhancement/Gust  Alleviation  (ME/GA) 

These  modes  control  the  airplane  through  wing  leading  and  trailing 
edge  surface  commands  and  stabilon  commands. 

When  engaged,  the  AFCS  modes  operate  parallel  to  and  through  the 
MFCS  to  control  the  airplane.  This  configuration  allows  the  AFCS  sys¬ 
tem  to  be  disengaged  at  anytime  without  compromising  the  safety  of  the 
aircraft. 

MMEUyjjjB  CAMBER  CONTROL 

The  MCC  mode  continuously  positions  the  MAW  wing  surfaces  to 
their  maximum  lift/drag  positions  during  both  maneuvering  and  steady 
state  flight  for  a  given  Mach  No.  and  lift  coefficient.  The  wing 
surface  positions  are  computed  based  on  entering  stored  tables  of  wing 
leading  and  trailing  edge  flap  positions  that  are  functions  of  lift 
coefficient,  wing  sweep  and  Mach  number.  These  stored  tables  are 
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based  upon  picking  points  of  maximum  L/0  from  the  wind  tunnel  generat¬ 
ed  drag  polars.  These  data  have  a  single  adjustment  for  dynamic 
pressure  effects.  The  flaps  on  the  right  and  left  wings  are  commanded 
symmetrically  for  this  mode.  The  MCC  leading  and  trailing  edge  flap 
commands  are  extracted  from  tables  where  independent  variables  are 
airplane  lift  coefficients,  Mach  No.  and  wing  sweep.  Lift  coeffi¬ 
cient  is  calculated  from  measured  normal  acceleration  g,  computed 
weight  based  on  initial  empty  weight  and  remaining  fuel,  measured 
dynamic  pressure  and  reference  area.  The  calculated  MCC  flap  commands 
are  filter_J  by  2.0  rad/sec  first  order  lags.  The  acceleration  input 
to  the  lift  coefficient  calculation  is  prefiltered  by  a  20  rad/sec 
lag . 

CRUISE  CAMBER  CONTROL 

The  CCC  mode  is  an  on  line  optimization  process  that  varies  the 
trailing  edge  flap  position  to  maximize  horizontal  velocity.  This 
mode  will  engage  when  the  altitude  hold  mode  is  engaged  at  constant 
power  level  angle.  The  mode  operates  by  incrementally  moving  the 
trailing  edge  flaps  either  up  or  down  in  such  a  fashion  as  to  maximize 
forward  speed.  The  operation  of  the  mode  is  based  on  comparing  actual 
and  predicted  forward  velocity  changes  as  related  to  flap  movement. 
The  mode  uses  the  integral  of  longitudinal  acceleration  to  compute 
forward  speed  changes.  The  velocity  changes  are  sampled  at  5  sec 
intervals  to  form  a  data  set  used  in  estimating  the  two  parameters  for 
a  first  order  longitudinal  velocity  predictor  based  on  least  square 
techniques.  With  this  predictor,  the  future  forward  speed  of  the  air¬ 
craft  can  be  estimated.  The  algorithm  will  next  make  a  flap  change 
and,  after  allowing  enough  time  for  short  period  dynamic  effects  to 
decay,  will  make  a  velocity  change  measurement.  This  measurement  is 
compared  to  the  estimated  velocity  change  if  the  flap  was  not  deflect¬ 
ed.  If  the  actual  speed  change  is  greater  than  the  estimated  speed 
change,  then  the  most  recent  flap  change  was  beneficial  and  the  pro¬ 
cess  continued.  If  not,  the  optimum  flap  setting  has  already  been 
reached. 
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MAN ELVER.  LOAD  00 NTROL  (MLC ) 

The  MLC  system  prevents  the  wing  root  bending  load  from  exceeding 
the  limit  load  level.  The  MLC  mode  has  no  effect  on  control  surfaces 
or  the  operation  of  the  other  AFCS  modes  when  the  wing  root  bending 
moment  is  below  the  threshold  of  95  percent  of  the  limit  load.  Above 
the  95  percent  threshold,  the  MLC  system  commands  the  outboard  trail¬ 
ing  edge  surfaces  to  limit  the  root  bending  moment  to  the  threshold 

value.  At  all  times,  both  midspan  and  inboard  surfaces  are  free  to 

respond  to  other  MFCS  and  AFCS  commands.  The  MLC  mode  has  independent 
right  and  left  wing  systems  for  asymmetric  flight  conditions.  For  cer¬ 
tain  operating  configurations,  the  MLC  system  also  commands  the 
stabilon  through  pitch  damper  inputs  to  control  undesirable  airplane 
transients.  To  achieve  the  aim  of  limiting  the  wing  root  being  moment 
to  an  acceptable  level,  the  MLC  system  automatically  shifts  the  wing 
center  of  pressure  inboard  by  moving  the  outboard  flap  upward  to 

reduce  the  lift  on  the  outboard  section  of  th  wing.  By  moving  the 
center  of  pressure  inboard,  increased  lift  is  allowable  and  can  be 

demanded  by  other  system  inputs  (although  slightly  higher  angle  of 
attack  is  required) .  By  acting  automatically  to  limit  bending  moment 
a  more  severe  maneuver  can  be  commanded.  The  approach  used  for  the 
MLC  mode  is  to  compute  an  estimate  of  the  bending  moment  at  the  wing 
root  using  accelerations,  weight,  dynamic  pressure,  mach  number,  lead¬ 
ing  and  trailing  edge  surfaces  positions  and  stabilon  deflection  rate 
(filtered)  and  if  this  estimate  is  greater  than  95%  of  the  threshold, 
command  the  outboard  flags  until  the  95%  threshold  is  not  exceeded. 

MANEUVER  ENHANCEMENT  GUST  ALLEVIATION  (ME/GA)- 

The  purpose  of  this  mode  is  to  significantly  improve  the  airplane 
normal  acceleration  response  to  a  pilot  command  while  simultaneously 
reducing  cockpit  normal  acceleration  response  to  turbulence.  The 
ME/GA  mode  is  designed  to  integrate  these  two  functions  such  that  the 
performance  of  each  function  is  in  no  way  degraded  by  the  presence  of 
the  other  function  in  the  mode.  The  ME/GA  mode  was  designed  using 
linear  quadratic  Gaussian  regulator  theory  to  generate  a  full  state 
optimal  gain  matrix  and  Kalman  filter.  A  modal  residualization  pro¬ 
cess  was  used  to  reduce  the  full  state  system  to  a  lower  order  system 
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suitable  for  implementation  on  a  flight  computer.  The  requirement  of 
improved  command  response  has  been  realized  by  using  an  explicit  model 
follower  feedforward  controller  in  the  control  system.  The  feedfoward 
controller  gains  are  synthesized  as  part  of  the  optimal  regulator 
solution.  The  ideal  model  is  a  first  order  lag  with  a  break  frequency 
tuned  to  provide  a  good  response  without  excessive  overshoot.  The 
ME/GA  mode  uses  three  sensors:  normal  acceleration  at  the  cockpit 
nz  pitch  rate,  and  pitch  stick  position.  In  addition,  leading  edge 
position  and  trailing  edge  position  commands  are  input  from  either  the 
manual  mode  or  MCC  AFCS  mode.  The  ME/GA  system  is  designed  to  command 
the  flaps  to  these  latter  inputs  in  the  absence  of  any  other  commands. 
The  sensor  measurements  are  used  as  inputs  to  the  Kalman  state  estima¬ 
tor.  In  order  to  provide  the  same  overall  stick  sensitivity,  the 
sensed  and  commanded  accelerations  are  compared  with  the  difference 
used  to  generate  a  stabilon  command.  This  causes  the  airplane  to 
respond  to  the  commanded  acceleration  level. 

2. 7. 2. 3  MFCS  and  AFCS  Implementation 

The  MFCS  will  be  implemented  and  flight  tested  in  the  first  phase 
o£  the  program.  Upon  completion  of  the  manual  flight  test,  the  manual 
system  command  processors  will  be  reprogrammed  to  add  the  MCC  and  CCC 
automatic  control  system  modes.  Following  evaluation  of  MCC  and  CCC 
modes,  two  additional  command  processors  will  be  added  to  handle  the 
MLC  and  ME/GA  modes.  The  two  additional  command  processors  (AFCS  pro¬ 
cessors)  will  communicate  directly  to  the  manual  command  processors. 
The  two  manual  command  processors  will  communicate  with  each  other  on 
a  cross-channel  data  bus  and  individually  to  the  AFTI/F-111  flight 
control  system.  The  cross  -  channel  data  bus  provides  a  means  for 
failure  checking  between  command  processors.  The  cross  -  channel  data 
bus  is  also  interfaced  to  a  digital  data  interface  unit  for  flight 
data  recording  and  telemetry.  A  top-level  system  diagram  is  shown  in 
Figure  2.7-4. 
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Figure  2.7-4  Top-Level  System  Diagram 


2.7.3  Program  Status  and  Plans 


The  wings  have  been  delivered  and  installed  on  the  TACT  F-lll 
aircraft  at  NASA/Dryden.  The  command  processor  software  has  completed 
software  verification  testing  in  a  software  test  laboratory  which 
utilized  the  command  processors  and  hardware  test  panels  which  emulat¬ 
ed  many  of  the  aircraft  functions.  Preliminary  functional  testing  has 
been  performed  on  the  aircraft  which  has  verified  the  MFCS  functional 
requirements.  This  functional  testing  was  performed  on  the  aircraft 
using  two  command  processors  which  had  passed  hardware  functional 
testing,  but  were  not  yet  soldered,  sealed  or  had  undergone  environ¬ 
mental  tests. 

The  purpose  of  this  preliminary  aircraft  functional  test  was  to 
identify  any  hardware  interface  discrepancies  and  any  other  discrepan¬ 
cies  which  might  exist  while  changes  could  be  made  more  easily  before 
the  units  were  sealed.  As  a  result  of  this  preliminary  functional 
testing,  minor  problems  were  identified  in  interfaces,  design,  and 
test  procedures.  These  problems  have  been  resolved  and  the  aircraft 
MFCS  functional  tests  are  scheculed  for  the  March/April  time  frame. 
Upon  completion  of  the  aircraft  functional  tests,  ground  vibration 
tests  will  be  performed  followed  by  final  preflight  tests.  Flight 
test  is  expected  to  be  initiated  in  the  August/September  time  frame. 

2.7.4  Work  Accomplished 

SCT  has  been  providing  systems  and  software  support  to  AFWAL/FIMS 
for  the  AFTI/F-111  MAW  program.  This  support  has  occured  in  three 
areas;  software  management,  simulation  support,  and  control  system 
design. 

2. 7. 4.1  Software  Management  Support 

SCT  has  provided  software  support  to  address  the  management 
aspects  of  the  AFTI-F-111  MAW  Manual  Flight  Control  System  (MFCS)  and 
Automatic  Flight  Control  System  (AFCS)  software  development.  This 
support  consisted  of  developing  and  maintaining  a  system  level  under¬ 
standing  for  the  MFCS  and  AFCS  and  actively  participating  in  the 
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software  development  management  milestones.  Support  which  was  provid¬ 
ed  consisted  of: 

-Review  of  contractor  software  development  plans  to 
assess  whether  planned  management  and  technical  activites 
will  provide  adequate  Air  Force  and  Boeing  visibility 
and  control  into  the  software  development  of  the  MFCS 
and  AFCS. 

-Review  of  contractor  monthly  progress  reports  to  maintain 
currency  on  system  and  software  development  status. 

-Active  participation  in  the  software  requirements  reviews, 

PDRs ,  and  CDRs  to  include  review  of  software  documentation 
and  assessment  of  the  adequacy  of  requirements,  plans, 
and  specifications  presented. 

-On  a  continuing  basis,  review  of  system  level  documents 
and  technical  reports  to  stay  current  with  design  and 
development  activities  and  maintain  a  system  level 
understanding. 

Because  the  MAW  software  development  is  a  multi-phased 
development  effort,  a  number  of  planned  software  versions  will  evolve 
during  the  course  of  the  program.  SCT  has  worked  closely  with  the  Air 
Force  and  NASA  in  performing  a  critical  review  of  the  contractor 
software  development  plan,  and  in  turn  provided  guidance  in  the  areas 
of  software  documentation,  software  configuration  control,  and 
software  development  milestone  reviews.  SCT  has  reviewed  all  develop¬ 
ing  contractor  software  documents  and  many  system  documents,  providing 
document  review  comments  to  the  Air  Force.  Also,  SCT  has  actively 
participated  in  all  system  and  software  design  reviews  of  the  MAW  pro¬ 
gram,  providing  comments,  trip  reports,  and  generating  RIDs  (review 
item  disposition) ,  as  required. 

2. 7. 4. 2  Simulation  Development  Support 

SCT  has  also  provided  simulation  development  support  at 
NASA/Dryden.  This  support  consisted  of  detailed  review  of  system  and 
software  requirements  for  the  MAW  MFCS  and  AFCS,  and  assistance  in 
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implementation  of  these  requirements  into  a  functional  simulation  of 
the  MAW  system.  An  example  of  specific  activities  includes: 

-Integration  of  aeromodel  data  with  AFTI/F-111 
real-time  simulation. 

-Update  of  various  simulation  models  such  as  landing 
gear  and  ground  effects. 

-Optimize  models  for  real-time  execution. 

-Generation  of  aeromodel  check  cases. 

-Verification  of  aeromodel  data  packages. 

-Rehost  of  simulation  onto  MODCOMP  computers. 

-Development  and  integration  of  software  to  add  MAW 
control  panel  to  simulation. 

SCT  provided  daily  support  in  the  development  modification  and 
update  of  the  AFTI/F-111  MAW  simulation.  Support  was  also  provided 
during  real-time  data  gather  and  demonstration  runs. 

2. 7. 4. 3  Control  System  Design  Support 

SCT  was  requested  to  look  at  an  alternative  approach  to  control¬ 
ling  wingshape  design  (see  Section  2.5.2).  SCT  performed  a  study 
whose  objectives  were  to  define  potential  multivariable  control  law 
structures  which  are  suitable  for  active  wingshape  control,  recommend 
design  and  algorithm  implementation  techniques,  and  assess  the  design 
impact  of  a  multivariable  active  wingshape  control  system. 

The  scope  of  this  study  was  limited  to  a  preliminary  assessment 
of  multivariable  control  applied  to  the  AFTI/F-111.  The  study  inves¬ 
tigated  the  integrated  design  of  a  multivariable-multifunctional 
control  system  based  on  the  application  of  modern  control  design  tech¬ 
niques.  The  AFTI/F-111  MAW  is  an  example  of  the  need  for  such 
integrated  design  methods  as  an  aircaraft  that  combines  wing  shape 
control  (which  is  mechanized  to  continuously  control  the  leading  and 
trailing  edge  deflections)  with  conventional  aircraft  controls  (i.e., 
stabilon,  throttle,  rudder)  for  enhanced  aircraft  performance  and  han¬ 
dling  qualities.  This  type  of  control  system  requires  integration  of 


aircraft  stabilization,  configuration  management  and  structural  load 
control  functions  that  can  benefit  the  operational  performance  of  the 
aircraft  for  takeoff,  climb,  cruise,  combat,  and  landings  modes  of 
flight.  The  actual  mix  between  control  functional  requirements  and 
modes  of  flight  varies  with  aircraft  type  (i.e.,  penetration  bomber, 
large  transport,  cruise  missile  carrier  or  fighter)  . 

Modern  control  design  techniques  are  well  suited  for  the  develop¬ 
ment  of  complex  control  systems  such  as  the  MAW,  for  two  reasons. 
First,  multivariable  synthesis  techniques  offer  a  systematic  method 
for  optimizing  control  law  structures  for  multiple  control  require¬ 
ments  (e.g.,  drag  minimization,  lateral  control,  and  maneuver  load 
alleviation  for  maneuvering  flight)  where  a  number  of  sensor  signals 
and  control  surfaces  are  available  for  the  control  law.  Second, 
parameter  identification  techniques  would  be  used  to  generate  flight 
condition  and  camber  corrections  for  optimizing  the  aircraft  perfor¬ 
mance  and  the  required  signals  for  the  multivariable  control  law.  The 
use  of  parameter  identification  for  on-line  flight  performance  optimi¬ 
zation  could  also  be  extended  to  include  the  aircraft's  propulsion 
system  (i.e.,  inlet,  internal,  and  nozzle  geometry). 

Specific  design  features  of  the  designed  MAW  multivariable  multi- 
mode  flight  control  system  are  in  SCT  Report  No.  5339-522-1,  Active 
Wingshape  Control  System  Feasibility  Design  Study,  August  1982. 


2.7.5 


SCT  provided  assistance  to  the  Air  Force  in  the  areas  of  software 
management  simulation  development  and  control  system  design  support. 

The  area  of  software  management  addressed  those  aspects  of  the 
developing  contractor's  approach  to  planning  and  managing  the  develop¬ 
ment  of  flight  software.  That  is,  SCT  reviewed  the  contractor's 
approach  to  software  development  and  monitored  the  contractor  activi¬ 
ties  during  the  development  process. 

With  the  current  trends  in  computer  hardware,  software 
development  costs  are  becoming  the  major  portion  in  the  acquisition 
cost  of  systems  involving  hardware  and  software.  In  order  to  reduce 
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these  costs  software  management  must  work  toward  the  following  objec¬ 
tives: 

-Reduce  resource  expenditures  in  software  development. 

-Improve  software  development  resource  estimating. 

-Avoid  duplicate  development  efforts. 

-Improve  quality  of  software. 

-Reduce  software  maintenance  efforts. 

The  Boeing  Company  has  established  company  software  standards 
which  they  profess  to  use  for  software  development  efforts.  SCT 
reviewed  these  standards  and  found  them  to  be  an  excellent  approach  to 
software  development.  The  first  major  impact  of  these  standards  was 
that  software  documentation  would  not  be  prepared  according  to 
MIL-STD-483/490 ,  but  would  use  phased  software  development  documents 
which  more  closely  follow  the  actual  development  process.  SCT 
approves  of  this  approach  and  recommends  that  this  approach  be  used  in 
future  Air  Force  software  development  efforts.  For  the  MAW  program, 
because  of  the  reduced  magnitude  of  software  development  effort,  a 
short  form  of  these  documents  consisting  of  5  documents  rather  than  10 
documents  was  used.  These  documents  included  (1)  Requirements,  (2) 
Design,  (3)  Test,  (4)  Operating  Instructions,  and  (5)  Version  Descrip¬ 
tion,  which  collectively  cover  the  gambit  of  software  development 
activities  from  requirements  definition  to  software  update  and  mainte¬ 
nance. 

Boeing  also  has  excellent  software  standards  covering 
configuration  management,  software  quality  assurance,  software 
development,  and  software  review.  However,  the  application  of  these 
standards  to  a  specific  project  sometimes  requires  an 
interpretation/learning  process  by  individuals  unfamiliar  with  this 
approach  and  hesitant  to  use  it.  SCT  performed  in  a  software  manage¬ 
ment  review  role  of  Boeing's  software  management  approach.  The 
scheduled  formal  reviews  (i.e.,  Requirements  Review,  PDR,  CDR,  etc.) 
provided  milestones  within  the  software  development  process  which 
allowed  assessment  of  the  progress  of  the  development.  Also,  occa¬ 
sional  on-site  engineering  reviews  of  design  and  development  efforts 
provided  insight  to  actual  software  development  practices  being  used. 
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In  general,  for  the  MAW  program  these  reviews  (both  formal  and 
engineering)  were  valuable  in  keeping  the  Air  Force/NASA  informed  of 
the  development  progress  and  also  in  making  the  Boeing  personnel 
adhere  to  their  software  standards. 

In  future  development  efforts,  the  Air  Force  should  initially 
make  certain  that  the  development  contractor  have  a  well  defined, 
phased  software  management  approach  with  scheduled  review  milestones. 
As  the  software  development  progresses,  the  Air  Force  should  actively 
participate  in  the  software  review  process  to  assure  that  initial 
development  plans  are  being  met  and  that  these  plans  are  still  aligned 
with  final  design  goals. 
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